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Because  of  range  limitations  imposed  by  speed  and  power  supplies,  covert  launch 
and  recovery  of  Autonomous  Underwater  Vehicles  (AUVs)  near  the  operating  tuca  will  be 
required  for  their  use  in  many  military  applications.  Thi.s  thesis  documents  the 
implementation  cf  precision  conuol  and  planning  facilities  on  the  Phoenix  AIJV  that  will 
be  required  to  support  recovery  in  a  small  tube  and  provides  a  preliminary  study  of  issues 
incolved  vvith  AUV  recovery  by  submarinc.s. 

Implementation  invoices  the  development  of  low-level  behaviors  for  sonar  and 
vehicle  control,  mid  level  tactics  for  recovery  planning,  and  a  mission-planning  system  for 
translating  high-level  goals  into  an  executable  mis.sion.  Sonar  behaviors  consist  of  modes 
for  locating  and  tracking  objects,  while  vehicle  control  behaviors  include  the  ability  to 
drive  to  and  maintain  a  position  relative  to  a  tracked  object.  Finally,  a  mission-planning 
system  allowing  graphical  .specification  of  mission  objectives  and  recovery  parameters  is 
mipkmented, 

Results  of  underwater  virtual  world  and  in-water  te.sting  show  that  precise  AUV 
control  based  on  sonai  data  can  be  implemented  to  an  accuracy  of  less  than  six  indies  and 
that  this,  degree  of  preci.sion  is  sufficient  for  u.se  by  higher-level  tactics  to  plan  and  control 
recovery.  Additionally,  the  mission-planning  expert  system  has  been  shown  to  reduce 
mission  planning  time  by  approximately  two  thirds  and  results  in  missions  vvith  fewer 
logical  and  programming  errors  than  manually  generated  mi.ssions. 
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I.  INTRODUCTION 


A.  NPS  CENTER  FOR  AUV  RESEARCH  AND  THE  PHOENIX  AU  V 


This  thesis  is  concerned  v^ith  the  mission  planning,  mission  control,  and  precision 
niiuieuvering  required  to  support  recovery  of  the  Phoenix  autonomous  underwater  vehicle 
(AUV)  in  a  simulated  torpedo  tube.  Specific  issues  covered  include  automated  mission 
planning,  finite  state  mission  control,  recoveiy  jiath  planning,  recovery  tube  detection  and 
localization,  and  precise  maneuvering  control  for  docking. 

The  Naval  Postgraduate  School  (NPS)  has  been  actively  involved  in  autonomous 
underwater  vehicle  research  for  a  number  of  years.  Recently  the  NPS  Center  for  AUV 
Re.search  was  established  to  explore  concepts  in  the  design  and  control  of  AUVs.  As  tliey 
are  developed,  concepts  are  implemented  on  the  Phoenix  AUV,  a  236  centimeter  long, 
neutrally  buoyant  vehicle  weighing  approximately  200  kilograms.  Research  goals  include 
proving  the  feasibility  of  AUV  use  in  shallow  water  mine  countermeasure  (MCM) 
operations  by  implementation  of  a  working  proof-of-concept  system  and  furthering  the 
state  of  the  art  in  the  field  of  AUVs  in  general.  Specific  research  areas  have  included  AUV 
control,  navigation,  software  architecture  and  mis.don  planning. 

The  Phoenix  AUV  (Figure  1)  is  controlled  by  two  on-board  computers  connected 
via  a  local-area  network  (LAN).  'Phis  LAN  can  be  operated  independently  or  can  be 
connected  to  other  networks  for  real-time  monitoring  of  mission  progress.  Vehicle 
phy.sica)  control  is  implemented  using  two  lateral  thrusters,  two  vertical  thrusters,  two  aft 
propellers,  and  eight  control  planes. 


Jntil  recently  in-water  testing  of  Phoenix  had  been  lliuitcd  to  the  Center’s  7.5  meter 


by  7.5  meter  by  2.5  meter  test  tank  and  the  sub-Olympic  size  NPS  pool.  Salt  water  testing 
began  in  January  1 996  at  Moss  Landing,  California.  Future  testing  will  be  conducted  at  all 
three  sites  and  preparations  arc  in  progress  for  open-water  testing  in  Monterey  Bay. 


B.  MOTIVATION 


Counter- mine  warfare  has  recently  become  an  important  issue  in  the  eyes  of  the 
Navy’s  senior  leadership  [Boorda  95].  Joint  doctrinal  changes,  especially  the  inUoduction 
of  littoral  warfare  ts  a  primary  mission  area,  have  pushed  MCM  operations  to  the  forefront. 
Mines  have  many  characteristics  that  make  them  attractive  to  coastal  nations  that  might  be 
the  focus  of  littoral  v.'arfare.  Mines  aie  inexpensive,  readily  available,  easy  to  use,  difficult 
to  detect  and  disable,  and  have  proven  very  effective  against  naval  and  amphibious 
operations.  The  inadequacy  of  corrent  United  States  MCM  capabilities  is  amply 
documented  [Cheney  92j. 

The  inherently  covert  nature  of  AUVs  makes  them  an  appealing  platform  for 
shallow-water  MCM  operations.  A  small  AU  V  launched  and  recovered  covertly  miglu  be 
capable  of  mapping  or  neutralizing  a  mine  field  without  being  detected.  This  ought  to  be 
true  even  if  the  mine  field  is  actively  monitored  by  hostile  forces. 

C.  PROBLEM  DESCRIPTION 

Since  a  small  AUV  will  inevitably  have  a  limited  power  supply,  it  will  need  to  be 
launched  and  recovered  close  to  its  operating  area.  While  this  constraint  does  not  pose  a 
significant  problem  in  civilian  AUV  applications,  the  need  for  covertness  may  preclude 
launching  the  AUV  from  aircraft  or  ships  for  military  missions  such  as  MCM  operations. 
The  obvious  solution  is  to  use  submarines  to  launch  and  recover  AU  V.'r’.  Of  specific  interest 
therefore  is  the  launch  and  recovery  of  AUVs  using  a  submarine’s  torpedo  tubes. 

Launch  of  an  AIJV  fiom  a  torpedo  Uibe  is  a  simple,  rnatter  since  launching  is  what 
torpedo  tubes  are  designed  for.  Recovery  is  much  more  complex  and  is  not  a  declared 
capability  of  any  submarine.  Recovery  of  an  AUV  via  submarine  toiqiedo  tube  can  be 


broken  down  into  three  subproblems;  torpedo  tube  location  and  classification,  recovery 
path  planning,  and  physical  control  of  the  AUV  maneuvering  along  the  recovery  path. 

Torpedo  tube  localization  and  classification  involves  using  the  AUV  position,  the 
tube’s  expected  position,  and  active  sonar  (or  some  other  means)  to  precisely  locate  the 
AUV  relative  to  the  torpedo  tube,  [Murphy  96]  uses  the  term  extoprioception  to  describe 
this  type  of  localization  which  involves  the  position  of  the  vehicle  relative  to  objects  in  the 
operating  environment.  This  is  in  contrast  to  exteroception,  which  is  the  localization  of 
objects  in  the  environment  relative  to  the  AUV.  The  precise  nature  of  the  motion  required 
for  torpedo  tube  recovery  dictates  that  estimates  of  AUV/tube  relative  positioning  be 
continually  refined  while  the  recovery  is  in  progress  in  order  to  ensure  the  AUV  is  safely 
maneu\’ering  using  the  most  accurate  infonmtion  possible. 

Once  the  tube  has  been  located  and  classified,  a  safe  path  into  the  tube  must  be 
determined.  The  AUV  will  attempt  to  travel  along  this  path  during  the  recovery.  A  smooth 
path  must  therefore  be  planned  from  the  location  of  the  AUV  at  the  beginning  of  the 
evolution  to  its  desired  location  at  the  end.  This  path  may  need  to  be  periodically  replanned 
as  the  position  of  the  tube  relative  to  the  AUV  is  refined  and  updated. 

The  final  aspect  of  torpedo  tube  recovery  involves  accurate  movement  of  the  AUV 
to  a  series  of  desired  positions  and  orientations  relative  to  the  toipiedo  tube.  Once  the  tube 
has  been  identified  and  a  path  planned,  the  AUV  must  be  capable  of  accurately  following 
the  commanded  path.  Motion  control  must  be  robu.st,  even  in  the  presence  of  uniform  or 
variable  ocean  currents. 

D.  THESIS  GOALS 

A  large  amount  of  research  has  been  directed  at  executing  MUM  mis.sions  with  the 
Phoenix  AUV,  but  recovery  problems  have  not  yet  been  addre.ssed  in  any  depth.  The 
primary  goal  of  this  thesis  is  to  begin  adapting  the  software  architecture  of  the  Phoenix 


AU  V  to  enable  torpedo  tube  recovery.  Specifically,  developments  to  the  Phoenix  software 
will  enable  reliable  recovery  in  a  simulated  torpedo  tube  in  the  Underwater  Virtual  World 
(UVW)  [Brutzman  94],  UVW  results  are  verified  by  in- water  experiments  to  the  greatest 
extent  possible.  Issues  to  be  dealt  with  include  global  positioning  of  the  recovery  toipedo 
tube,  recovery  path  planning,  and  local  AUV  po  rtioning  using  active  sonar'  and  a 
mathematical  model  during  recover)'. 

E.  THESIS  ORGANIZATION 

The  Rational  Behavior  Model  (RBM)  is  a  three  layer  software  aichitecture  designed 
to  emulate  the  command  stmcture  of  a  manned  submarine  [Byrnes  96].  It  is  within  the 
(;ontext  of  this  architecture  that  tliis  thesis  is  organized.  This  chapter  is  devoted  to  the 
motivation,  problem  discussion  and  goals  for  this  project.  Chapter  II  discusses  previous 
work  in  the  area  of  AUV  recovery  and  related  work  conducted  on  the  Phoenix  AUV  in 
particular.  Chapter  III  discusses  the  core  problems  addre.ssed  by  this  work,  the  general 
re.search  technique  used  in  this  project  and  the  design  of  experiments.  Chapters  IV,  V.  and 
VI  discuss  implementation  of  features  of  this  project  at  the  three  layers  of  the  RBM. 
Specifically,  C'hapter  IV  di.scusses  implementation  at  the  lowest  layer  (execution  level). 
Chapter  V  discusses  implementation  at  the  middle  layer  (tactical  level).  Chapter  Vi 
di.scusses  implementation  of  the  top  layer  (strategic  level)  and  the  off-line  automatic 
mission  generation  expert  system.  Chapter  VII  focuses  on  the  conduct  and  results  of 
experiments.  Conclusions  and  recommendations  for  future  work  are  presented  in  Chapter 
Vlll. 

Three  appendices  are  also  included  in  this  thesis.  Appendix  A  provides  instructions 
for  obtaining  on-line  resources.  Appendix  B  provides  a  listing  of  the  available  commands 
in  the  execution  level  command  language  described  in  Chapter  IV  and  in  | Brutzman  94], 


Appendix  C  provides  instri’ctions  on  die  use  of  the  mission  planning  expert  syston 
described  in  Chapter  VI. 

Source  code  for  all  sofbvare  developed  during  the  conduct  of  this  research  is 
available  as  part  of  an  on-line  software  reference.  Instructions  for  obtaining  this  and  other 
on-line  resources  are  provided  in  Appendix  A.  Addiri onally,  source  code  is  published  in 
[Davis  96], 


11.  RELATED  WORK 


A.  INTRODUCTION 

There  are  several  potential  AUV  applications  in  addition  to  MCM  that  aie  being 
explored  by  various  organizations  around  the  world.  Environmental  monitoring, 
oceanographic  research  and  maintenance/monitoring  of  underwater  structures  arc  just  a 
few  examples.  AUV’s  are  attractive  in  these  areas  for  a  number  of  reasons.  Because  of 
their  size  and  their  nonreliance  on  human  operators,  they  are  potentially  le.ss  expensive  to 
purchase  and  operate  than  manned  or  remotely  operated  underwater  vehicles.  AUV’s 
might  be  deployed  in  larger  numbers,  for  longer  periods  and  on  shorter  notice  [Smith  94, 
Bellingham  94].  While  remotely  operated  vehicles  (ROV’s)  partially  share  these 
advantages,  the  requirement  of  a  physical  connection  between  the  ROV  and  a  host  platform 
or  ship  limits  the  ROV’s  operating  range  and  the  required  tether  can  be  easily  fouled.  The 
latter  problem  can  be  particularly  limiting  in  restricted  environments  such  as  kelj)  forests 
or  under  ice  [Bellingham  94].  Given  the  potential  applications  and  advantages  of  AUV’s, 
it  is  no  wonder  that  military,  academic  and  commercial  organizations  around  the  world  are 
conducting  research  using  these  vehicles. 

This  chapter  is  divided  into  two  major  parts.  The  first  covers  re.search  efforts  of 
other  organizations  that  have  been  directed  towards  the  recovery  of  AUVs.  This  section  is 
by  no  means  a  complete  survey  of  world-wide  AUV  research.  For  a  broader  overview  of 
this  .subject,  the  reader  is  advised  refer  to  [UUST  95,  AUV  96].  The  second  .section  of  this 
chapter  describes  related  research  conducted  on  Phoenix.  In  this  latter  section  emphasis  is 
given  to  the  overall  control  architecture  of  Phoenix  and  the  u.se  of  sonar  for  local-area 
navigation. 


B,  RECOVERY  OF  AUTONOMOUS  UNDERWATER  VEHICLES 


1.  Massachusetts  Institute  of  Technology  (MIT) 

Odyssey  11  (Figure  2)  is  a  robot  developed  by  the  Massachusetts  Institute  of 
Technology  (MIT)  Sea  Grant  College  Program.  Odyssey  11  was  built  for  the  conduct  of  two 
specific  scientific  missions:  undc.f-ice  mapping  and  rapid  response  to  volcanic  events  at 
mid-ocean  ridges.  Odyssey  11  is  215  centimeters  in  length,  59  centimeters  diameter  and 
displaces  140  kilograms.  Major  design  goals  were  to  minimize  drag,  power  requirements 
and  size  while  maximizing  hull  strength  and  endurance.  These  sometin'ies  contradictory 
goals  were  necessary  to  support  long  missions  under  extreme  environmental  conditions. 
[Bellingham  94] 


Figure  2;  The  Odvssev  H  AUV  fMIT  Home  Page  96). 

Physical  control  of  Odyssey  U  is  via  a  single  aft-mounted  thruster  and  four  control 
planes  mounted  on  the  aft  portion  of  the  fuselage.  The  absence  of  lateral  and  vertical 


thrusters  means  that  Odyssey  11  must  maintain  forward  motion  in  order  to  maneuver. 
Minimum  maneuvering  speed  is  approximately  0.5  meters  per  second  and  turn  radius  is 
approximately  five  meters  [Bellingham  94].  Programmed  vehicle  behaviors  must  take 
these  maneuvering  characteristics  into  account. 

Odyssey  II  u.ses  three  fixed  sonars  for  obstacle  detection/avoidance  and  an  altitude 
sonar  that  can  be  oriented  vertically  to  maintain  altitude  from  the  sea  floor  or  overhead  ice. 
A  low-frequency  hyperbolic  long-baseline  acoustic  system  is  used  for  vehicle  navigation 
during  the  conduct  of  a  mission  [Bellingham  92].  Mission  sensors  include  various 
oceanographic  instruments,  a  still  camera  and  a  video  recorder.  The  primary  on-board 
computer  is  a  40MHz  68030  operating  under  the  OS-9  real-time  operating  system.  This 
computer  is  connected  to  several  microcontrollers  that  are  re.sponsible  for  control  of  some 
of  the  vehicle’s  subsystems.  [Bellingham  94] 

Logical  control  of  Odyssey  II  uses  a  layered  software  system.  The  primary  building 
block  of  the  system  is  referred  to  a.s  a  behavior.  An  individual  behavior  is  re.sponsible  for 
a  specific  type  of  action.  Examples  of  behavior  types  include  homing,  collision  detection, 
survey  with  navigation,  and  race  track.  The  current  values  and  prioriti  .  of  all  active 
behaviors  as  well  as  toe  sensor  data  is  maintained  in  a  vehicle  state  structure.  This  stmcture 
is  evahiated  by  the  dynamic  controller  which  actually  commands  the  vehicle’s  physical 
actuators.  [Bellingham  94] 

Recoveiy  of  Odyssey  II  relics  on  homing  and  uses  a  commercially  available  ultra- 
short  baseline  (USBL)  acoustic  system  as  a  beacon.  The  homing  behavior  uses  range  and 
bearing  updates  from  the  UBSL  system  to  guide  Odyssey  II  into  a  capture  net.  The  system 
has  been  siicces.sfully  tesced  in  under-ice  operations  with  rhe  vehicle  typically  returning  to 
within  30  cm  of  the  homing  beacon  [Bellingham  94|.  While  navigational  accuracy  of  30 
cm  is  no!  sufficient  to  control  an  entire  torpedo-tube  recovery,  a  system  such  as  this  may 
be  idea!  for  th  :  ncar-field  or  close-proximity  navigation  portion  of  the  recovery.  An 


acoustic  navigation  system  providing  accuracy  to  less  than  one  meter  might  be  used  to 
position  the  AUV  relative  to  the  recovery  tube,  so  that  on-board  AUV  sensors  can  acquire/ 
classify  the  recovery  tube  and  control  the  final  portions  of  the  recovery. 

2.  Florida  Atlantic  University 
a.  Ocean  Voyager  II 

Ocean  Voyager  II,  shown  in  Figure  3,  is  the  result  of  a  joint  research  effort 
conducted  by  the  Ocean  Engineering  Department  of  Florida  Atlantic  University  (FAU)  and 
the  Marine  Science  Department  of  the  University  of  South  Florida.  Ocean  Voyager  II  is  an 
AUV  similar  in  size  and  structure  to  Odyssey  II  and  is  intended  for  coastal  oceanographic 
research.  The  vehicle  is  240  centimeters  long  and  displaces  approximately  250  kilograms. 
Maximum  speed  is  1 .54  meters  per  second  and  endurance  is  approximately  eight  hours. 
[Smith  94 1 


Figure  3;  The  Ocean  Voyager  II  AUV  [FAU  96]. 


Like  Odyssey  II,  Ocean  Voyager  II  uses  a  single  aft  mounted  thmster  and 
four  control  planes  mounted  on  the  aft  pornon  of  the  fu.selage.  Again,  this  control 
arrangement  requires  Ocean  Voyager  II  to  maintain  foiward  speed  to  maintain  posture 


control.  This  constraint  is  not  a  problem  given  the  type  of  mission  for  which  the  vehicle  is 
intended.  While  Odyssey  II  is  designed  for  deep-water  operations,  the  missions  for  which 
Ocean  Voyager  II  is  intended  requite  the  vehicle  to  cruise  in  a  regular  pattern  at  a  fixed 
altitude  above  the  bottom  [White  96,  Smith  94].  Specific  missions  include  monitoring  sea 
grass,  monitoring  macro-algae  beds  and  evaluating  the  effects  of  storm-front  passage 
[Smith  94]. 

While  the  missions  for  which  Ocean  Voyager  II  is  designed  are  fairly 
.specific  in  nature,  each  mission  requires  different  sensor  packages.  The  sensor  payload  is 
contained  immediately  aft  of  the  AUV’s  nose  cone  and  is  designed  to  be  modular  in  nature. 
This  modularity  allows  for  fairly  simple  but  specialized  sensor  packages  installed  for  each 
mission  [White  96]. 

Logical  control  of  Ocean  Voyager  II  is  implemented  by  a  fuzzy  rule-based 
algorithm.  The  control  algorithm  is  similar  to  that  of  Odyssey  II  except  that  instead  of 
behaviors,  Ocean  Voyager  II  control  modes  use  the  results  of  fuzzy  rules  to  compute 
control  commands  and  confidence  levels.  The  output  of  each  mode  is  evaluated  by  the 
fuzzy  weighted  decision  arbiter  which  determines  the  actual  control  outputs.  Abort  and 
avoid  modes  provide  for  vehicle  safety.  Track,  stable  and  no-operation  modes  provide  for 
data  collection  during  normal  operation.  Additional  modes  for  waypoint  navigation, 
docking  or  other  behaviors  are  possible  but  have  not  yet  been  tested.  [Smith  96] 


b.  Recovery  of  Ocean  Voyager  II 

Significant  simulation-based  research  in  the  area  of  AUV  recovery  has  been 
conducted  using  Ocean  Voyager  II.  In  [Rae  92,  Rac  93]  the  possibility  of  using  fuzzy  logic 
to  control  recovci^  by  a  submarine  was  explored,  while  [White  96]  documents  more  recent 
research  into  using  the  same  general  procedure  to  control  docking  with  a  fixed  stmcture. 
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The  fuzzy  docking  algorithm  uses  a  “virtual  funnel”  to  control  the  AlIV 
tov/ards  the  goal.  The  virtual  funnel  is  represented  by  fuzzy  rules  that  define  desired 
motion  for  the  AUV  given  its  current  position.  As  long  as  the  vehicle  remains  inside  the 
region  defined  by  the  virtual  funnel,  it  will  proceed  towards  the  docking  target.  If  the  AUV 
wanders  outside  the  funnel,  it  will  be  vectored  towards  a  new  stinting  position  and  will 
begin  again.  The  size  and  shape  of  the  docking  funnel  are  determined  by  vehicle 
characteri.stics  and  the  external  environment.  A  strength  of  the  fuzzy  docking  algorithm  is 
that  obstacle  avoidance  is  an  integral  consideration.  A  flow  chart  representation  of  the 
fuzzy  docking  algorithm  is  depicted  in  Figure  4.  [Rae  92,  Rae  93,  White  96] 


Figure  4;  Fuzzy  Docking  .Algorithm  [Smith  96]. 

[Rae  92,  Rae  93]  assume  that  the  AUV  has  accurate  relative  position 
information  for  itself  and  the  dock  throughout  the  docking  procedure.  While  this 
assumption  precluded  immediate  implementation  in  the  vehicle,  tests  documented  in  these 
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papers  indicated  that  the  algorithm  was  valid  so  long  as  accurate  navigational  data  was 
obtained.  Specifically  [Rae  92]  documents  simulation  results  of  fuzzy  docking  algorithm 
use  to  dock  with  a  stationary  submarine.  [Rae  93]  expands  on  this  work  by  simulating  the 
use  of  the  algorithm  to  dock  with  a  moving  submatine  and  al.so  attempts  to  model  suction 
forces  and  wake  turbulence  created  by  a  moving  .submarine.  [White  96]  documents 
simulation  results  that  indicate  that  if  a  boundary  area  is  included  in  the  virtual  funnel  to 
account  for  navigational  inaccuracy  as  depicted  in  Figure  5,  the  algorithm  is  still  valid. 
Simulation  results  documented  in  [White  96]  were  based  on  expected  navigational 
accuracy  using  the  DivetrackerTM  system,  An  interesting  additional  result  was  that  the 
navigational  accuracy  of  the  DivetrackerTM  system  may  be  sufficient  to  control  the  entire 
docking  maneuver. 


3.  Shenyang  Research  and  Development  Centre  of  Robotics 

The  Shenyang  Research  and  Development  Centre  of  Robotics  is  a  research 
organization  in  the  People’s  Republic  of  China.  The  AUV  being  developed  by  this  group 
is  named  Explorer.  While  Explorer  is  similar  to  the  Odyssey  U  and  Ocean  Voyai’cr  II  in 
operating  capabilities  and  characteristics,  it  is  interesting  and  relevant  in  this  context 
because  of  its  recovery  device.  Although  Explorer  is  operated  from  a  surface  ship,  launch 
and  recovery  takes  place  underwater. 

Four  options  were  considered  for  Explorer  s  launch  and  recovery  system:  recovery 
in  the  center  well  of  a  support  ship,  recovery  using  a  .submarine,  recovery  using  a  semi- 
submersible  platform,  and  recovery  using  a  submersible  platform.  The  final  system  uses  a 
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underwater  launch  and  recovery  procedure  was  ba.sed  on  two  factors:  the  difficulty  of  a 
surf  ace  recovery  in  high  sea  states  and  Explorer  ^  relatively  poor  navigational  capabilities 
on  the  surface.  [Ditang  92] 


Figure  5:  Virtual  Docking  Funnel  for  the  Fuzzy  Docking  Algorithm  [Smith  96], 


The  launcher  itself  is  a  cage-like  structure  that  is  lowered  by  crane  to  a  depth  of  30 
to  50  meters.  The  launcher  has  two  locking  arms  for  securing  the  AUV  when  it  is  in  the 
launcher,  a  television  camera  for  monitoring  of  the  recovery  and  two  vertical  thrusters 
which  are  used  to  maintain  the  launcher  at  the  specified  depth.  Explorer  uses  an  ultrashort 
baseline  (USBL)  navigation  system  and  an  on-board  video  camera  to  navigate  during  the 
recovery  process.  A  drawing  of  the  launcher  configuration  is  depicted  in  Figure  6. 
[Ditang  92] 
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Figure  6:  The  Explorer  AUV  Launcher  (units  are  mm)  [Ditang  92], 


The  Explorer  recovery  process  consist.s  of  five  steps.  First  the  launcher  is  lowered 
to  the  appropriate  depth.  Once  lowered  to  the  Specified  depth,  the  launcher  thrusters 
automatically  maintain  the  launcher's  depth  so  that  motion  control  by  the  ship-board 
operator  is  not  required.  Next  Explorer  uses  the  USBL  system  to  navigate  to  a  position  in 
front  of  the  launcher.  Once  within  visual  range,  the  on-board  video  camera  is  used  to 
identify  reference  points  on  the  launcher  and  provide  precise  relative  position  information 
during  the  final  phase  of  the  recovery.  The  launcher  operator  uses  the  launcher’s  camera 
to  determine  when  the  AUV  is  in  the  final  recovery  position.  Once  the  AUV  is  in  place  the 
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locking  arms  are  closed,  and  both  launcher  and  AUV  can  be  raised  into  the  ship,  A 
depiction  of  an  Explorer  recovery  using  the  launcher  can  be  seen  in  Figure  7.  [Ditang  92] 


While  recovery  of  an  AUV  in  this  fashion  is  a  far  cry  from  recovery  within  a 
torpedo  tube,  it  is  noteworthy  in  two  respects.  First,  this  sy.stem  requires  clo.se  coordination 
between  the  recovering  ship  and  the  AUV.  If  the  launcher  is  not  at  the  appropriate  depth 
or  location,  or  if  the  locking  arms  are  not  operated  properly,  the  recovery  will  not  be 
successful.  This  coordination  between  the  AUV  and  its  recovery  vehicle  is  a  basic 
assumption  upon  which  successful  recovery  is  ba.sed  and  is  di.scussed  in  more  detail  in 
[Gwin  92]  and  [Chapuis  96].  Second,  Explorer  uses  multiple  navigation  techniques  during 


different  phases  of  the  recovery.  The  on-board  television  camera  provides  accurate  local 
navigation  during  the  final  phase  of  the  recovery,  but  video  is  of  no  use  in  locating  the 
launcher  from  a  distance  of  more  than  a  few  feet.  The  USBL  navigation  system  allows 
Explorer  to  get  close  to  the  launcher,  but  does  not  provide  enough  precision  to  actually 
enter  the  launcher. 

The  recovery  procedure  being  considered  for  Phoenix  is  similar,  using  the 
DivetrackerTM  system  to  navigate  to  a  position  from  which  the  recovery  tube  can  be 
acquired  and  identified  using  the  two  on-board  sonar  systems.  The  Phoenix  sonars  are  then 
used  for  precision  maneuvering  into  the  tube  using  techniques  described  in  [Healey  94]  and 
[Marco  96a]. 

4.  Centre  Technique  Des  Systemes  Navals  (CTSN) 

As  part  of  a  larger  feasibility  study  on  the  design  of  recoverable  unmanned 
underwater  vehicles  (UUV’s),  the  Centre  Technique  Des  Systemes  Navals  (CTSN), 
located  in  Toulon  France,  has  attempted  to  identify  functions  upon  which  UIJV  launch  and 
recovery  from  submarines  rely  and  the  environmental  factors  affecting  each  of  these 
functions  [Chapuis  96).  For  the  most  part  the  functions  and  environmental  factors 
identified  are  relevant  to  the  launch  ana  recovery  of  both  AUV’s  and  ROV’s.  Functions 
a’e  divided  into  two  types:  main  functions  and  constraint  functions.  Main  functions  are 
those  functions  that  directly  accomplish  high  level  goals.  Constraint  functions  are  those 
that  facilitate  the  successf  ul  completion  ol'  main  functions  or  are  inherent  subfunctions  of 
a  main  function. 

For  UUV  recovery,  one  main  function  and  six  constraint  functions  were  identified. 
These  functions  and  the  factors  effecting  them  are  .shown  iti  ''  'ble  1.  The  main  function  is 
simply  the  transition  of  the  UUV  from  the  (jpen  sea  into  the  submarine.  Constraint 
hinctions  include  communication  with  the  submarine,  entry  into  the  recovery  system. 


straight  navigation  despite  swell  and  waves,  adapting  to  depth  effects  such  as  pressure  and 
light  level,  obstacle  avoidance,  and  resistance  to  the  marine  environment.  By  performing 
this  assessment  process  lepeatedly,  the  problem  requirements  of  torpedo-tube  docking  with 
a  submarine  are  fully  specified.  [Chapuis  96] 


Function 

Criteria 

Tran.sition  from  open  .sea  into 
submarine 

Communicate  with  submarine 

Communication  svstem  tvnc 

attenuation 

intensity 

frcriucnty  hand 

range 

Enter  recovery  system 

vchiele  path 
vehicle  speed 

vehicle  size 

recovery  device  size 

recovery  device  sensors 

Navigate  straigiu  in  the  pres 
enee  of  waves  and  eurreiit 

.vavc  signilieant  height 
wave  pcritxi 

wave  direction 

current  suced 

current  direction 

Adapt  to  clcptli  effects 

depth 

temperature 

Avoid  ohstaclc.s 

obstacle  density 

obstacle  speed 

obstacle  direction 

distance  olistadc/vehicic 

Resist  the  marine  environment 

acidity 

Table  1 .  ULIV  Recovery  Functions.  Underlined  criteria  are  considered  dominant.  After 

[Chapuis  96] 


5.  Institute  for  Systems  and  Robotics,  Institute  Superior  Tecnico 

Still  another  AUV  research  project  is  being  conducted  by  the  Institute  for  Systems 
and  Robotics  Institute  Superior  Tecnico  (IST)  of  Lisbon,  Portugal.  The  research  vehicle  of 
this  organization  is  named  Marius.  However  this  research  is  relevant  in  the  context  of  this 
thesis  (specifically  Chapter  VI)  because  of  the  mission  control/planning  features  rather  than 
the  vehicle  itself. 

High  level  mission  control  of  Marius  uses  a  mathematical  .stnicture  called  a  Pftri 
net  [Cassan(  as  93,  Peterson  81],  A  Petri  net  is  a  type  of  graph  consisting  oi'  transitions, 
places  and  arcs.  When  used  for  AUV  mission  control,  transitions  correspond  to  actions  to 
be  undertaken  by  the  vehicle,  places  correspond  to  preconditions  for  execution  of  a 
transition  or  results  of  transition  execution,  and  arcs  are  used  to  connect  transitions  to  the 
appropriate  precondition  and  postcondition  places,  A  token  is  used  to  mark  all  places 
whose  conditions  are  satisfied.  When  all  of  a  transition’s  precondition  places  contain 
tokens,  the  transition  is  enabled.  Since  multiple  transitions  may  be  enabled  at  the  same 
time,  Petri  nets  arc  well  suited  to  re{)rcsenting  parallelism  in  a  system. 

The  COR. \L  development  environment  has  been  develoiied  by  1ST  as  the  interface 
for  generating  missions.  This  system  uses  a  graphical  interface  to  define  the  Petri  net 
representing  a  mission,  and  assign  specific  tasks  to  the  transitions.  A  CORAL  Engine  has 
also  been  developed  to  accept  and  execute  Petri  net  descriptions.  Details  of  the  CORAL 
system  can  be  found  in  (Oliveira  9()|. 

Recent  rese  arch  has  been  conducted  to  u.se  the  CORAL  .sy.stem  for  defining  and 
executing  missions  with  other  AUVs.  Towards  this  end,  a  mission  was  successfully 
executed  by  the  Phoenix  AUV  using  CORAL  without  making  any  modification  to  Phoenix 
software  1  Healey  96].  The  results  of  this  re.search  are  an  indication  <if  the  general 
ecjui  valence  of  .several  AUV  nuiltipledcvel  mission  control  strategies. 
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C.  THE  PHOENIX  AUTONOMOUS  UNDERWATER  VEHICLE 


1.  Hardware  Configuration 

The  Phoenix  AUV  is  235  centimeters  in  length,  41  centimeters  in  width,  25 
centimeters  in  height  and  displaces  198  kilograms  [I,eonhardt  96],  The  main  body,  which 
houses  Phoenix'  electronic  and  power  equipment,  is  constiucted  of  aluminum  and  is 
designed  to  be  water  tight  to  eight  meter  depth.  The  tree-flood  nose  cone  is  constructed  of 
fiberglass  and  houses  the  vehicle’s  sonars,  depth  .sensor  and  waterspeed  probe.  Physical 
control  of  Phoenix  is  via  two  aft  thiusters,  two  lateral  cross-body  thrusters,  two  vertical 
cross-body  thrusters,  and  eight  control  planes.  The  rectangular  hull  fomi  atid  large  number 
of  propulsion  effectors  are  intended  to  facilitate  precise  position  and  orientation  control 
whether  the  vehicle  is  hovering  or  transiting.  The  external  layout  of  Phoenix  is  depicted  in 
Figure  8. 
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Figure  8:  Phoenix  E.xtcrnal  Configuration  [Lconhardt  96 1. 


Phoenix  is  controlled  by  two  on-board  computers.  The  vehicle’s  actuators  and 
sensors  are  monitored  and  controlled  by  processes  running  on  a  30  MHz  Gespac  68030 
computer  under  the  OS-9  real-time  operating  system.  Higher-level  mission  control,  data 
collection  and  planning  arc  handled  by  processes  running  on  a  Sun  Voyager  workstation 
under  the  Unix  operating  system.  The  two  computers  are  connected  by  an  on-board 
Ethernet  local-area  network  (LAN).  The  vehicle  also  has  an  external  Ethernet  connector 
which  can  be  used  to  communicate  with  the  on-board  computers  from  an  external  network. 
This  external  connection  is  primarily  u.sed  for  mission  loading  and  data  retrieval  and  is 
simply  terminated  during  untethered  missions. 

Phoenix'  primary  navigational  equipment  consists  of  a  differential  Global 

Positioning  System  (GPS)  receiver  and  a  Divetrackcr™  short  ba.selinc  acoustic  tracking 
system.  Phoenix'  u.se  of  the.se  .systems  is  covered  in  detail  in  [McClarin  96]  and 
[Scrivener961.  In  addition,  Phoenix  has  a  turbine  flow-meter  probe  for  water  speed 
measurement,  a  depth  cell,  pitch,  roll  and  yaw  rate  gyros,  and  heading  and  vertical  gyros. 

Phoenix  has  three  sonars:  a  PSA900  altimeter  sonar,  an  STIOOO  mechanically 
steered  sonar  and  an  ST725  mechanically  steered  sonar.  The  PSA900  and  STIOOO  sonars 
are  controlled  from  the  GESPAC  computer  while  the  ST72.6  i;:  controlled  by  the  Sun 
Voyager.  The  STIOOO  has  a  one-degree  conical  beam  and  a  360-degree  sweep  [Tritech 
International  Ltd.  92a].  The  ST72.6  also  has  a  360-degree  sweep,  with  a  horizontal  width 
of  2. .3  degrees  and  a  vertical  width  0(28  degrees  [Tritech  International  Ltd.  926]. 

Other  on-board  equipment  includes  two  leak  detectors,  two  lead  acid-gel  batteries 
capable  of  providing  approximately  two  hours  of  power  for  the  vehicle’s  computers  and 
motors,  and  hydrogen  absorbers  located  throughout  the  vehicle.  The  internal  layout  of 
Phoenix  is  depicted  in  Figure  9. 
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Figure  9:  Phoenix  inlernal  Hardware  Configuration  [l^onhardt  96]. 
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2,  'File  Rrtlsor.al  Behavior  Model  (RBM) 
a.  ijverview 

T  he  Rtif  icnal  Behavior  Modei  (RBM)  is  a  three-layer  software  architecture 
for  the  control  o)  autonoirtous  vehicles  [Byrnes  93,  Byrnes  961.  RBM  attempts  to  closely 
(hp  rorrtTrinn/i  Qf nw'Tlii’6*  nf  m«nr»pH  eHiy-vc  <jo 

.  i>  .  e.j_  .'I-'.  v/l  l<.  i  tpo  ».%.j  iii  a  i\.y.  lujr  vi 

(stralsgic  level  )  is  responsible  for  defining  higii-Jcscl  goals  and  controlling  overall  mission 
sepuencirig.  'Fht  slrategic  level  of  RBM  roughly  corresponds  to  the  commanding  officer 
ol  H  riiauiicd  ship,  i  he  middle  layer  (tactical  level)  is  responsible  for  interpreting  the  high- 
ieve.l  guirlnijcc  irf.'m  thu  strategic  level  and  issuing  control  commanus  to  the  lowest  layer 
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(execution  level)  fMarco  96b].  In  addition  to  direction  of  the  execution  level,  the  tactical 
level  is  responsible  for  navigation,  obstacle  dete<  tion/classification,  obstacle  avoidance, 
path  planning,  and  system  monitoring  [Leonhardt  96].  The  responsibilities  of  the  tactical 
level  are  analogous  to  those  ol  the  officer  watch  team  on  a  manned  ship.  The  execution 
level  is  responsible  for  interfacing  with  the  vehicle’s  hardware  to  produce  desired  physical 
responses.  This  layer  corresponds  to  the  watch-.standers  on  a  manned  ship.  In  Phoenix 
implementation  of  RBM  the  strategic  and  tactical  levels  lun  on  the  Sun  Voyager  while  the 
execution  level  runs  on  the  Gespac  computer.  Communication  between  the  tactical  and 
execution  levels  is  via  BSD  Unix  sockets  while  communication  between  processes  at  the 
tactical  level  is  via  Unix  pipes  [Leonhardt  96]. 
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Figure  10  The  Rational  Behavior  Model  Software  Architecture  [Holden  95]. 


h.  Strategic  Level 

An  RBM  .strategic-level  mi.ssion  is  structured  as  a  deterministic  finite 
automata  (DFA),  sometimes  referred  to  as  a  finite  state  machine  [Ilopcroft  79],  Fach  high 
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level  mission  goal  (or  phase)  represents  a  node  (or  state)  in  the  DFA.  Transitions  within 
the  DFA  occur  whenever  a  phase  succeeds  or  fails.  Upon  phase  completion  or  failure, 
subsequent  phases  to  execute  are  specified  by  the  transitions  of  the  DFA,  Thus  each  node 
has  two  exit  transitions;  one  for  successful  phase  completion  and  one  for  phase  failure.  On 
first  consideration,  limiting  each  node  of  the  DFA  to  exactly  two  exit  transitions  might 
seem  to  restrict  the  versatility  of  the  RBM  strategic  level.  However  any  DFA  of  arbitrary 
complexity  can  Idc  restructured  as  a  logically  equivalent  binary  DFA  because  any  decision 
tree  can  be  restructured  into  an  equivalent  binary  decision  tree  [Rowe  88].  Thus  this 
restriction  on  the  DFA  structure  in  no  way  limits  the  versatility  of  the  strategic  level.  A 
graphical  representation  of  an  RBM  strategic-level  DFA  for  a  simple  search  mission  is 
shown  in  Figure  1 1 .  Implementation  of  the  strategic  level  as  a  structured  DFA  provides  a 
flexible  means  of  describing  and  .sequencing  sophisticated  missions. 

In  order  to  execute  a  mission,  the  strategic  level  requires  three  software 
components.  The  first  pait  is  a  DFA  specification  of  the  mission.  The  second  part  is  a 
mission  controller  that  will  control  transitions  through  the  DFA  and  initiate  the  appropriate 
phases  at  the  appropriate  times.  The  final  part  is  a  set  of  primitive  strategic-level  goals  that 
provide  the  syntax  and  semantics  of  a  command  language  from  the  strategic  to  the  tactical 
level.  These  goals  are  implemented  as  messages  to  the  tactical  level. 

The  set  of  available  messages  to  the  tactical  level  constitute  what  amounts 
1.0  a  tactical-level  command  language.  Commands  are  used  to  tell  the  tactical  level  to  start 
timers,  specify  hover  points  and  waypoints,  conduct  searches  and  to  perform  other  high- 
level  operations  that  make  up  the.  strategic  level’s  primitive  goal  set. 


Figure  1 1 :  A  Simple  RBM  Strategic  Level  Search  Mission. 
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A  final  noteworthy  aspect  of  the  RBM  strategic  level  is  the  absence  of 
mathematical  computation.  The  RBM  architectural  structure  permits  arithmetic 
computations  to  be  performed  only  in  the  lower  two  RBM  layers.  In  fact  the  strategic  level 
as  initially  proposed  in  [Byrnes  93]  further  required  that  numerical  data  be  confined 
entirely  to  the  lower  levels  of  the  RBM.  It  has  sub.sequently  been  found  desirable  to  permit 
numerical  data  at  the  strategic  level  as  part  of  the  high-level  goal  specifications  [Leonhardt 
96],  although  this  level  remains  concerned  only  with  initiating  phases  and  waiting  for 
.successful  completion  or  failure,  This  example  alludes  to  a  larger  issue  that  must 
constantly  be  dealt  w'ith:  what  facilities  need  to  be  placed  at  what  layers  of  a  multi-layer 
software  architecture?  In  this  instance,  the  final  deci.sion  was  based  more  on  how  the  data 
\»'as  being  used  than  what  type  of  data  it  was. 

c.  Tactical  Level 

On  Phoenix  several  concurrent  processes  are  used  to  implement  the  tactical 
level.  These  processes  consist  of  the  officer  of  the  deck  (OOD)  module,  the  sonar  module, 
t.he  navigator  module  and  the  reclaimer  module  [Leonhardt  96],  Future  plans  include  the 
implementation  of  an  engineer  module  that  will  be  responsible  for  monitoring  and 
troubleshooting  vehicle  systems  and  detecting  .system  failures  and  degradations. 

The  OOD  module  receives  commands  from  the  strategic  level  and  state 
information  from  the  execution  level.  The  OOD  u;;e.s  this  information  to  direct  the  other 
tactical  level  modules  and  the  execution  level  [Leonhardt  96].  Additionally,  the  OOD 
module  determines  when  individual  phases  have  completed  or  failed  and  responds 
accordingly  to  strategic  level  queries  concerning  the  status  of  the  cun'ent  phase.  OOD 
respovrs 's  to  .strategic  level  queries  are  always  binary  in  nature  and  indicate  a  yes  or  no 
respon.se  [Byrnes  96],  More  detailed  infonnation  concerning  the  implementation  of  the 
OOD  module  can  be  fountl  in  [Leonhardt  96]. 


The  sonar  module  is  responsible  for  controlling  tlie  ST725  sonar  and 
interpreting  the  sonar’s  data.  During  most  operations  the  sonar  is  swept  back  and  forth 
directly  in  front  of  the  AUV  in  order  to  find  and  classify  objects  in  Phoenix'  path,  but  it  can 
also  be  used  to  conduct  a  360  degree  search  from  a  hover  [Campbell  96].  The  sonar  module 
uses  parametric  linear  regression  to  construct  line  segments  from  sonar  returns  and  a  rule 
based  expert  system  to  connect  line  segments  into  polygons.  This  sonar  return 
classification  process  is  described  in  detail  in  [Brutzman  92]  and  [Campbell  96]. 

The  navigator  module  is  responsible  for  maintaining  accurate  current 
position  information.  A  Kalman  filter  is  used  to  combine  GPS,  differential  GPS, 
Divetracker™  and  dead  reckoning  data  to  compute  Phoenix’  position.  Implementation 
details  of  the  navigator  module  can  be  found  in  [McClarin  96]. 

The  replanner  is  responsible  for  planning  safe  paths  around  obstacles 
detected  by  the  sonar  module.  Replanner  implementation  is  covered  in  detail  in 
[Leonhardt  96]. 

d.  Execution  Level 

The  execution  level  is  impleirnented  as  a  single  closed-loo])  process.  Each 
loop  iteration  consists  of  three  phases;  sense,  decide  and  act.  The  execution  level  process 
reads  sensors  and  computes  values  for  parameters  that  do  not  have  a  dedicated  sensor 
during  the  sense  portion  of  the  loop.  The  execution  level  process  then  uses  this  infomiation 
to  detcniiine  what  control  inputs  are  necessary  to  achieve  the  most  recent  tactical  level 
command.  Finally  appropriate  commands  are  sent  to  each  control  actuator.  [Bums  96] 

In  addition  the  execution  level  forwards  a  copy  of  the  updated  state  vector 
to  the  tactical  level  and  checks  for  a  new  command  from  the  tactical  level  each  time  through 
the  closed  loop.  The  complete  set  of  tactical  level  commands  also  constitutes  a  command 
language  |  Brutzman  96].  Each  command  consists  of  a  keyword  followed  by  a  number  of 
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parameters.  Execution-level  commands  are  available  for  explicitly  setting  control 
actuators,  setting  control  modes  and  updating  state  information  such  as  position  and  ocean 
current  that  is  maintained  at  the  execution  level.  The  most  recent  command  determines 
what  control  mode  the  AUV  will  use.  Available  control  modes  include  hover  control, 
waypoint  control,  lateral  control,  rotate  control  and  a  few  others.  A  subset  of  the  available 
commands  is  shown  in  Figure  12,  with  a  complete  listing  included  in  Appendix  B. 

A  final  responsibility  of  the  execution  level  is  the  initiation  of  a  reflexive 
mission  abort  under  certain  circumstances  [Bums  96].  A  mission  will  be  aborted  if  any  of 
the  following  occurs:  leak  detected,  low  battery,  imminent  collision  or  loss  of  primary 
navigation  system.  In  the  event  of  an  automatic  abort,  the  AUV  will  surface  as  quickly  as 
possible  using  thmsters  and  planes.  Upon  reaching  the  surface,  the  mi.ssion  v/ill  temiiuate. 

3.  Precision  Maneuvering  using  Sonar 

Recognizing  that  accurate  positioning  relative  to  objects  in  the  AUV’s  environment 
is  at  times  more  important  than  accurate  global  navigation,  research  into  using  Phoenix' 
sonars  for  navigational  purposes  was  begun  shortly  after  the  project’s  inception.  Early 
'■"■orts  focused  on  tactical  and  execution  level  coordination  and  command  sequencing  in 
order  to  facilitate  navigational  use  of  tire  sonar  and  on  implementing  primitive  behaviors 
for  control  and  use  of  vehicle  sonars. 
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WAIT 

# 

>Vaityrun  for  #  seconds 

RPM 

#  t##] 

Prop  ordered  rpm  values 

COURSE 

# 

Set  new  ordered  course 

TURN 

# 

Change  ordered  course  # 

RUDDER 

# 

Force  rudder  to  #  degrees 

DEPTH 

# 

Set  new  ordered  depth 

PLANES 

# 

Force  planes  to  #  degrees 

ROTATE 

# 

Open  loop  rot.ite  control 

NOROTATE 

Disable  open  loop  rotate 

LATERAL 

# 

Open  loop  lateral  control 

POSTURE 

#a 

#h  #c 

#d  #c  #f 

(x,  y,  z,  phi,  theta,  psi) 

POSITION  #  ##  [###]  Reset  dead  reckon 

i.e.  n.  vigation  fix 

ORIENTATION  ######  (phi,  theta,  psi) 

WAYPOINT  #X  #Y  [#Z] 

HOVER  [#X  #Y]  [#Z]  f#orientation] 
[#standoff-distanccJ 

GPS-FIX  Proceed  to  shallow  depth 

take  GPS  fix 

GPS-FIX  COMPLETE  Surface  GPS  fix  complete 
TRACE  Verbose  print  statements 


Figure  12:  Sample  Execution  Level  Commands  [Brutzman  941. 
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Early  results  were  published  in  [Healey  94].  The  first  significant  result  of  this 
research  was  the  implementation  of  vehicle  behaviors  that  used  the  newly  installed  lateral 
and  vertical  thrusters  to  obtain  hover-like  control.  These  behaviors  included  heading 
control,  depth  and  pitch  control,  lateral  speed  control  and  lateral  position  control. 
Behaviors  were  also  iinpleinented  for  use  of  the  sonars  and  included  center  sonar,  ping  and 
get  .sonar  range,  .step  sonar  (without  pinging)  and  initiate  or  reset  the  sonar  data  filters.  The 
philo,sophy  used  during  this  research  was  to  accurately  implement  functionality  at  the 
execution  level  before  attempting  to  use  these  behaviors  at  the  highei  RBM  levels 
[Healey  94]. 

Once  accurately  implemented,  the.se  behaviors  were  used  to  achieve  bottom¬ 
following  and  wall-following  behaviors.  These  behaviors  were  implemented  using  simple 
proportional  derivative  (PD)  control  laws  for  thmster  values.  Command  sequencing  and 
timing  were  also  addressed  at  this  .stage.  For  example,  it  is  futile  to  command  the  AU  V  to 
maintain  a  distance  from  a  wall  if  the  sonar  is  not  directed  towards  the  wall.  It  is  therefore 
the  responsibility  of  the  tactical  level  to  sequence  commands  to  the  execution  level 
appropriately,  [Healey  94] 

Recently  a  more  robust  method  of  AUV  positioning  relative  to  an  object  has  been 
developed.  This  method,  documented  in  [Marco  96a].  u.ses  the  STIOOO  to  locate  the  target 
and  uses  a  mathematical  model  to  navigate  to  the  commanded  location  relative  to  the 
object. 

The  position  of  the  object,  in  this  ca.se  a  0.5  meter  diameter  cylinder,  is  determined 
by  continually  sweeping  the  STIOOO  through  a  sector  centered  on  the  expected  bearing  of 
the  object.  The  sector  size  was  70  degrees  and  angular  resolution  of  the  sonar  was  1 .8 
degrees.  Sonar  returns  are  connected  into  segments  which  are  examined  to  rleteimine 
which  segments  represent  the  cylinder.  Simple  rules  based  on  the  cylinder’s  size,  shape 
and  location  are  used  to  determine  which  segments  comprise  the  cylinder.  Once  the 


cylinder  is  identified,  the  location  of  the  vehicle  in  a  navigation  frame  attached  to  the 
cylinder  with  axes  aligned  North  (x)  and  East  (y)  can  be  competed. 

Since  the  target  position  update  is  much  slower  than  the  ten  hertz  control  loop,  a 
simplified  mathematical  model  for  hydrodynamic  response  i.>  used  to  navigate  towards  the 
desired  relative  position  between  updates.  The  model  includes  drag,  added  mass  and  steady 
state  surge,  It  is  assumed  that  the  estimated  position  of  the  target  based  on  sonar  returns  is 
accurate  while  the  mathematical  model  is  inaccurate.  Therefore  the  current  model  e.stimatc 
is  re.set  whenever  the  sonar  updates  the  target  position.  Re.sults  repotted  in  [Marco  ^Iba) 
indicate  that  this  methodology  works  well  despite  known  inaccuracies  in  the  mathematical 
model. 

D.  SUMMARY 

Given  the  vdde  array  of  potential  u.ses  and  advantages  for  AUVs,  it  is  no  surprise 
that  research  is  being  conducted  by  numerous  organizations  worldwide.  There  are  however 
many  issues  that  remain  to  be  resolved.  One  of  these  is  AUV  recovery.  Several 
organizations  have  begun  work  on  different  recovery  techniques,  and  there  are  a  number  of 
systems  in  various  research  .stages.  Various  aspects  of  these  sy.stems  may  prove  helpful  in 
solving  the  problem  of  covert  launch  and  recovery  of  AUVs  from  subnnirines. 

Research  conducted  using  Phoenix  in  the  area  of  precision  maneuvering  using  sonar 
may  prove  helpful  as  well.  The  technique  of  combining  sonar  feature  extraction  and 
model-based  control  in  particular  forms  the  basis  of  a  significant  portion  oi  the  rc,search 
detailed  in  the  following  chapters. 
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III.  rp:search  methodology 


A.  INTRODUCTION 

'I’liis  chapter  is  intended  as  an  overview  of  the  tools  and  methodology  used  during 
this  research.  This  discussion  is  broken  into  three  sections.  Section  B  covers  the 
Underwater  Virtual  World  (UVW),  a  three  dimensional  (3D)  graphical  simulation  that 
supports  realistic  and  comprehensive  testing  of  an  AUV  in  the  laboratory.  Section  B  also 
examines  specific  of  the  UVW  and  the  enhancements  that  were  made  to  suppott  this 
rcsearcli.  Section  C  covers  implementation  and  testing  using  the  UVW.  Sectiirn  D  covers 
validation  of  vehicle  software  in  tlie  real  world. 

B.  UNDERWATKK  VIRTUAL  WORLD  (UVW) 

1.  Overview 

Implementation  and  testing  of  AUV  software  in  the  real  world  is  inherently  difficult 
for  a  number  of  reasons.  Logistical  requirements,  vehicle  maintenance  and  limited  power 
supplies  all  limit  the  amount  of  in-watcr  testing  that  is  possible  even  under  optimal 
ciicum.stances.  Additiontilly,  the  remote  environment  in  which  A'JVs  operate  precludes 
run  time  monitoring  and  can  make  data  evaluation  after  tire  fact  difficult  at  bc.st.  Finally 
the  unpredictability  of  the  marine  environment  may  make  it  difficult  or  imirossible  to 
conduct  tests  within  desired  environmental  parameters.  The  UVW  is  meant  to  address  all 
of  these  issues.  By  providing  ;i  means  of  cominchensively  and  accurately  testing  the  AUV 
in  the  laboratory,  the  UVW  allows  the  implementation  and  testing  of  vehicle  .software 
under  conditions  such  as  ocean  current,  ic.stiictcd-au  a  iiiancuvei  ing  and  riepths  that  are 
impractical  or  impossible  to  duplicate  in  real-world  testing.  [Brutzman  d4,  Brutzunan  95 1 

The  UVW  is  organized  in  two  fairly  distinct  pieces:  the  dynamics  module  and  the 
viewer.  The  dynamics  module  i  pre.sents  the  virtual  world  in  which  the  AUV  is  operating, 


Included  in  the  dynamics  module  are  vehicle  hydrodynamics  and  simulated  sensor 
response,  During  the  sense  portion  of  the  control  loop,  the  vehicle’s  execiition-lcvcl 
software  relays  a  copy  of  the  state  vector  from  the  previous  loop  to  the  dynamics  module. 
The  state  vector  includes  values  for  all  .salient  vehicle  characteristics  including  posture, 
velocities,  accelerations,  and  control  and  sensor  settings.  The  dynamics  module  ajtplies  tlie 
vehicle’s  hydrodynamics  formulas,  calculates  the  sen.sor  readings,  and  returns  an  updated 
state  vector  to  the  execution  level.  This  relay  of  state  vectors  between  the  dynamics  module 
and  the  execution  level  takes  the  place  of  physical  sensor  readings  and  actuator  response 
by  the  execution  level  in  the  real  world.  [Brutzman  941 

The  second  portion  of  the  UVW,  the  viewer,  provides  real-time  interactive  3D 
graphics  visualization  of  the  AUV  during  test  runs  in  the  UVW.  Control  .settings  (planes, 
propellers  and  thrusters)  and  sonar  ate  represented  graphically  allowing  intuitive 
qualitative  analysis  of  vehicle  performance.  Since  the  AUV  relies  only  upon  its  sensors, 
visualization  is  of  little  importance  to  the  vehicle  itself.  It  is,  however,  extremely  useful  to 
human  operators  to  be  able  to  see  how  the  AUV  is  performing  without  having  to  antilyze 
large  amounts  of  data.  The  diagnostic  value  of  this  tool  has  been  proven  on  an  almost  daily 
basis,  IBrutzman  94,  Brutzman  95 1 

The  viewer  is  written  using  the  OjX’n  Inventor  graphics  package  |  Wernecke  94). 
Based  on  the  Open  OL  graphics  librai7,  Open  Inventor  provides  an  obje-ct-oriented 
extension  to  the  C++  programming  language  for  scene  description  and  manipulation.  A 
.scene  is  repre.scnted  as  a  graph.  A  node  in  the  graph  represents  some  piece  of  infomiation 
about  the  .scene  such  as  an  object,  a  location,  a  material  or  a  .scaling  factor.  When  an  action 
(such  as  render)  is  applied  to  the  scene  graph,  the  graph  is  traversed  in  a  depth-first  fashion 
described  in  [  Wernecke  94)  and  the  action  is  applied  U)  each  node  in  turn.  Figure  1 3  shows 
the  Open  Inventor  scene  graph  used  to  represent  Phoenix.  A  rendered  depiction  of  a  .scene 
graph  I'roni  the  UVW  is  shown  in  Figure  14. 
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Figure  !3:  UVW  Viewer  Scene  Graph  Representation  of  Phoenix  |Brut/,inan  941 


Figure  14;  Visualization  in  the  UVW. 


A  second  feature  of  Open  Inventor  k  its  scene  description  language  [  Wernecke  94 1. 
4 'he  scene  aescripticn  provides  a  means  of  representing  scene  graphs  using  readable  text. 
Objects  defined  using  tite  scene  description  language  and  stored  in  files  can  be  loaded  into 
tl’.e  scene  graph  ri  run  arne.  Similarly,  any  portion  of  the  scene  graph  can  be  written  to  a 
file  at  nm-time  for  later  use  or  analysis.  The  ability  to  read  and  write  portions  of  the  scene 
grr.ph  at  oin  time  is  especially  useful  in  the  UVW  since  it  allows  arbitrary  objects  to  be 
loaded  into  r.iic  gvapl!  for  different  missions. 

2.  Soruii’  .Sii.iusfaiiori  and  Visualization 
a.  G(:.>fend 

T  he  nro;;t  .significant  limitation  of  the  initial  version  of  the  UVW  used 
during  this  thesi:-;  the  so.u;ii' model.  Until  recently  UVW  sonar  repre.sentation  was 
Uinitt  r!  to  ll;c  T’lT'JOO  .sch,'IV  .  .nd  only  to  the  25  ft  by  25  ft  CAUVR  test  tank.  This 
repi  eserit  .iiiou  used  a  siiripiified  planar  two-dimensional  trigonometric  model  described  in 
1  Rrutzman  94]  to  calculate  sonar  returns  based  on  a  known  AUV  position  within  the  tank. 
Otlici  ol/jects  preseut  in  die  scene  graph  were  not  represented  in  the  sonar  model.  In  order 
to  suppoit  this  and  other  lesearch,  a  more  general  sonar  model  representing  arbitiary 
targets  and  boib  tlie  oTTOOO  and  the  ST725  sonars  was  needed. 

'('lie  solution  produced  for  this  thesis  is  to  use  facilities  present  in  the  Open 
inventor  package  to  simulate  both  sonars.  One  of  tiie  actions  available  in  Open  Inventor  is 
a  ray-pick  action  (SoRayPickAction)  [Wernecke  94].  To  use  the  ray-pick  action,  the 
■staaing  point  of  the  ray  and  its  orientation  are  specified  and  the  action  is  applied  to  the 
scene  graph.  After  application,  the  ray-pick  action  returns  the  point  (if  any)  where  it  first 
intersected  an  object  in  the  scene  graph  to  which  it  was  applied.  If  the  origin  of  the  ray 
corresponds  to  the  location  of  a  sonar,  and  tlie  orientation  of  the  ray  corresponds  to  !  he 
oi  ientaUon  of  the  sonar,  then  the  distance  from  the  origin  of  the  ray  to  the  fu  st  intersection 


with  an  object  in  the  scene  graph  is  analogous  to  the  sonar  range.  Because  of  the  short 
ranges  involved  (less  than  thirty  meters),  bending  of  the  sonar  beam  is  assumed  to  be 
negligible  [Brutzman  94j.  Such  an  approximation  usually  remains  valid  at  longer  sonar 
ranges  (hundreds  of  meters)  but  depends  the  sound  .speed  profile  of  the  environment 
[Urick  83]. 

Since  sensor  modeling  is  handled  in  the  dynamics  module,  a  copy  of  the 
scene  graph  must  loaded  into  this  module  in  order  to  use  the  ray-pick  action  to  compute 
sonar  ranges.  While  the  dynainics  module  uses  a  copy  of  the  .scene  graph,  there  is  no  need 
for  the  dynamics  module  to  render  it.  By  maintaining  a  copy  of  the  scene  graph  in  the 
dynamics  module  without  rendering  it,  a  general  geometric  sonar  model  has  been 
implemented  without  sacrificing  real-time  performance  [Bnttzman  96]. 

Because  of  the  imperfect  nature  of  sonar  data  an  error  model  must  also  be 
implemented  in  order  to  accurate  iy  repre,sent  a  ,sonar.  In  the  absence  of  empirical  sonar 
error  data  on  the  STUKK)  and  ST72.‘)  sonars,  a  uniform  error  disti  ibution  has  been 
implemented  where  the  user  can  specify  the  maximum  ainuuiil  of  error  as  a  percent  of  the 
range.  The  sonar  range  including  error  is  computed  for  either  sonar  by  the  dynamics 
module  using  the  fonnula 

f^Rny  -.,rr„r  =  (rfl«d(2)  I  (Eq.  1  ) 

where  <•  is  ilie  maximum  error  percentage,  rand{2)  is  a  random  number  between  zero  and 
two  and  is  the  eiTor-free  sonar  inge  returned  by  the  geometric  sonar  model.  As  more 
empirical  error  data  becomes  available,  the  sonar  error  distribution  will  be  modified  to 
more  accurately  represent  the  pe'.formance  of  both  sonars.  A  uniform  error  distribution  can 
he  modified  to  provide  an  iubitrary  empirical  probability  distribution  in  a  straightforward 
inannci  as  explained  in  (Fish wick  9.51. 


b.  STIOOO  Sonar 


Because  the  STIOOO  sonar  is  a  one-degree  conical  (pencil-beam)  sonar,  its 
representation  using  the  ray-pick  action  is  fairly  straightforward  and  uses  a  single  ray.  The 
location  of  the  sonar  head  in  world  coordinates  is  computed  using  the  position  and 
orientation  of  the  AUV  in  world  coordinates  (data  that  is  encapsulated  in  the  AUV’s 
homogeneous  transformation  matrix)  and  the  position  of  the  STIOOO  in  AUV  body 
coordinates.  The  homogeneous  transformation  matrix  is  defined  as  [Craig  S9] 
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(Eq.  2) 


where  y ,  B  and  <()  are  the  AUV  azimuth,  elevation  and  roll  respectively,  {x  ,>1,2)1®  the 
AUV  position  in  world  coordinates,  and  c(X)  and  j(X)  are  cosine  and  sine  functions 
respectively.  U.sing  the  homogeneous  transformation  matrix  the  position  of  the  STIOOO 
sonar  in  world  coordinates  is  computed  as 


(Eq. 3) 
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where  {x^,  ,  -f,)  is  the  position  of  the  STIOOO  .sonar  head  in  AUV  body  coordinates. 


The  orientation  of  the  ray  repre.senting  the  STIOOO  is  found  in  a  similar 
fashion  using  the  orientation  of  the  sonar  beam  relative  to  the  AUV  and  the  rotation  matrix 
corresponding  to  the  orientation  of  the  AUV.  Since  the  STIOOO  sonar'  only  has  one  degree 
of  freedom  (DOF)  (rotation  about  the  z-axi.s),  the  unit  vector  representing  STIOOO  beam 
orientation  relative  to  the  AUV  can  l)e  computed  u.sing 


(Eq,  4) 


V,. 


COS(\J/*) 

sin(V(,) 

.  0  , 


where  y*  is  the  bearing  of  the  ST  1000  sonar.  The  vector  representing  the  orientation  of  the 


beam  unit  vector  in  world  coordinates  is  computed  using  the  fomiula 

V,  =  RV,  (Eq.  5) 

where  K  is  the  rotation  matrix  of  the  AUV  given  by  [Craig  89] 
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This  equation  corresponds  to  tlie  top  left  portion  of  the  matrix  of  Equation  3, 


(Eq.  6) 


Once  the  location  of  the  sonar  head  and  the  orientation  of  the  sonar  beam 


have  been  calculated  in  world  coordinates,  the  ray-pick  action  is  applied  to  the  scene  graph. 
The  di.stance  from  the  origin  of  the  beam  to  the  point  returned  by  the  ray-pick  action  is  then 
calculated  and  error  is  added  to  the  ri  suit  using  Equation  1. 


c.  ST725  Sonar 

The  ST725  sonar  differs  from  the  STIOOO  sonar  in  two  significant  respects 
that  complicate  its  repre.sentation  in  the  UVW.  Finst,  the  sonai'  beam  of  the  S4725  is  not  a 
pencil-beam  and  cannot  be  adequately  represented  by  a  single  ray  like  the  S'lTOOO. 
■Second,  the  data  returned  by  the  ST725  is  not  simply  a  range  to  the  nearest  target  but  rather 
a  data  structure  representing  the  strength  of  the  return  at  regular  intervals  out  to  the 
maximum  range,  nTiese  issues  are  both  dealt  with  by  fusing  the  resnlts  of  multiple  ray-pick 
actions. 

Before  de.scribing  the  actual  irnplcnrentation  of  the  ,ST725  sonar  in  the 
UVW,  it  is  important  to  understand  the  data  sb-ucture  returned  by  the  ST72.h  and  how  it  is 
inteqjreted  by  the  sonar  manager.  The  data  structure  returned  by  the  ,ST72.h  is  a  32  byte 
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sequence  that  is  divided  into  64  bins  of  four  bits  each.  A  bin  represents  the  strength  on  a 
scale  from  zero  to  15  of  the  sonar  return  at  a  certain  range.  The  range  represented  by  a  bin 
is  proportional  to  the  maximum  sonar  range  and  urn  be  approximated  linearly  using  the 
formula 

where  is  the  maxim?rm  range  .setting  of  the  sonar  and  bins  are  numbered  zero  to  63, 

The  tactical-level  sonar  manager  uses  this  data  structure  to  compute  a  .single 
range  for  the  ST725.  The  range  used  is  the  shortest  range  who.se  bin  value  is  above  a 
predefined  minimum  unless  the  value  of  a  bin  representing  a  longer  distance  is  significantly 
larger  (sb  ength  difference  greater  than  two).  If  this  is  the  case  the  longer  range  is  used. 
This  algorithm  is  discussed  in  more  detail  in  [Campbell  96]. 

The  UVW  implementation  of  the  Sl'725  uses  an  array  of  64  integers  to 
represent  the  returned  data  sboicture.  The  values  contained  in  this  an'ay  arc  determined  by 
the  results  of  13  ray-pick  actions  applied  to  the  scene  graph.  The  rays  for  all  13  ray-pick 
actions  originate  at  the  po.sition  of  the  ST725  .sonar  head  which  is  computed  using 
Equation  2  with  (i^, ,  )  representing  the  location  of  the  ST725  sonar  head  in  AU  V  body 

coordinates  (the  positions  of  the  ST725  and  STIOOO  .sonars  in  AUV  body  coordinates  is 
shown  in  Table  2).  The  vector  rcpre.senting  the  orientation  of  each  of  the  13  rays  in  AIJV 
body  coordinates  varies  above  and  below  the  horizontal  plane  of  the  sonar.  Ray 
orientations  are  computed  using 
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(Eq.  8) 


where  is  the  bearing  of  the  S'r725  sonar  and  rays  ;ue  numbered  from  zero  to  12.  This 
equation  differs  from  Equation  4  only  in  the  third  term  of  the  vector  which  allows  the  entire 
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vertical  sonar  beam  to  be  represented.  It  should  be  note.d  that  is  not  normally  a  unit 
vector.  While  conversion  to  a  unit  vector  is  a  simple  matter,  the  ray-pick  function  does  not 
require  orientation  specified  by  a  unit  vector,  so  the  conversion  is  not  performed  in  the 
interest  of  computational  efficiency.  Once  the  orientation  of  the  rays  in  AUV  body 
coordinates  has  been  calculated,  the  orientation  in  world  coordinates  can  be  computed 
using  Equation  5.  A  ray-pick  action  is  applied  to  the  .scene  graph  for  each  of  the  13  rays. 
Tire  range  to  the  point  returned  by  the  ray-pick  action  is  calculated,  and  the  value  stored  in 
the  array  of  integers  corresponding  to  the  appropriate  range  bin  is  incremented  by  one. 


.V,. 

STIOOO 

2,875 

-0.167 

0.3331 

ST72.‘i 

2,625 

-0,167 

-0  3333 

Table  2.  STIOOO  and  ST725  Positions  (ft)  in  AUV  Body  Coordinates. 

After  all  13  ray-pick  actions  the  error  free  sonar  range  is  computed  as  the 
range  corresponding  to  the  element  of  the  array  of  integers  with  the  highest  value.  If  no 
element  in  the  array  is  greater  than  one,  the  error  free  sonar  range  is  .set  to  zero.  Sonar  error 
is  then  added  to  the  error  free  range  using  Equation  1 .  Although  no  profiling  measurements 
were  performed  on  the  source  code,  this  oiieralion  appears  highly  efficient.  Tlie  sonar 
module  (operating  in  .scries  with  the  network  coniniunications  and  hydrodynamics  model) 
has  no  difficulty  executing  14  ray-picks  into  complex  scene  graphs  within  the  bounds  of  a 
ten  Hertz  update  rate.  Thus  computational  performance  of  the  arbitrary  geometric  soiuu 


model  is  excellent. 


d.  Visualization 

Once  ranges  have  been  computed  for  the  S'r725  and  ST  1000  sonars, 
visualization  using  the  viewer  is  straightforward.  The  goal  of  sonar  visualization  in  the 
LI  VW  is  to  enable  the  human  operator  to  see  the  operation  of  both  sonars.  Visualization 
has  proven  particularly  useful  for  detecting  and  ti  oubleshooting  sonar  control  algorithms 
since  it  provides  the  only  intuitive  verification  that  the  .sonars  are  being  controlled  as 
intended.  Numerous  experiments  conducted  in  the  course  of  this  research  have  shown  that 
sonar  visualization  is  crucial  to  tacdc  diagnosis  and  mission  rehearsal. 

Sonar  beams  are  represented  in  the  UVW  viewer  using  wireframe  cones. 
Nodes  representing  the  sonar  cones  are  placed  in  the  portion  of  the  scene  graph 
repre.senting  the  AIJV.  Additional  nodes  are  inserted  into  the  graph  to  represent  the 
po.sitions  and  orientations  of  the  sonars  relative  to  the  AUV.  In  order  to  accurately  depict 
the  pie-slice  sliape  of  the  ST725  sonar  beam,  the  vertical  scale  of  the  cone  representing  it 
is  increased  by  a  factor  of  1 2.  1’hey  are  depicted  as  wire  frames  rather  than  solid  objects  in 
order  to  preclude  the  sonai  cones  from  obscuring  other  portions  of  the  .scene. 

In  addition  to  positions  and  orientations  of  the  sonars,  target  range 
infonr'ation  is  depicted,  'lliis  is  accomplished  quite  simply  by  .scaling  the  length  of  the 
cones  representing  the  sonar  beams  to  the  range  of  the  appropriate  sonar  return.  If  the  ray- 
pick  sonar  range  is  zero  (no  scene  graph  object  was  within  range),  it  is  important  to  visually 
depict  lack  of  contact  as  well.  In  this  instance  the  .sonar  cone  length  is  scaled  out  to  the 
maximum  range,  and  for  visual  contrast  the  color  is  changed  and  the  wireframe  complexity 
IS  (iccrcs-Scd.  Tlic  ST  1000  sonui*  cone  is  red  if*  s  Vcilid  return  is  received  linri  yellow  if  no 
return  is  obtained.  The  ST725  sonar  is  corrc.spondingly  rendcrexi  in  magenta  or  white.  The 
portion  of  the  viewer  scene  graph  repre.senting  the  .ST72.5  sonar  is  shown  in  Figure  15, 
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Figure  15:  Open  Inventor  Scene  Graph  Representing  the  Sli'725  Sonar. 
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C.  IMPLEMENTATION  AND  TESTING  IN  THE  VIRTUAL  WORLD 


The  UVW  was  the  primary  tool  for  Phoenix  software  implementation  and  initial 
4  testing  during  the  conduct  of  this  research.  While  it  was  often  the  case  that  in-water  testing 

was  conducted  concurrently  with  UVW  testing,  for  safety  and  reliability  no  algorithms 
were  tested  in  the  water  prior  to  being  tested  in  tlie  UVW. 

4  The  gc  aeral  philosophy  used  duiing  the  conduct  of  this  research  was  .similar  to  that 

of  the  re.search  documented  in  [Marco  96].  Primitive  functionality  was  implemented  and 
tested  before  attempting  to  implement  higher  level  behaviors.  While  a  variety  of  low-level 
4  issues  were  not  identified  until  higher-level  behaviors  were  implemented,  these  were  the 

exception  rather  than  the  norm. 

The  first  issues  dealt  with  were  sonar  control,  target  acquisition  and  tracking  using 
4  the  .Sd'l ()()()  sonai'  Once  these  behaviors  were  implemented,  control  modes  were 

implemented  to  allow  Phoenix  to  maintain  a  commanded  relative  range  and  bearing  from 
a  sonar  target.  These  behaviors  form  tlie  base  upon  which  a  great  deal  of  this  resear  ch  rests. 
4  The  next  step  was  to  implement  higher-level  routines  that  visetl  these  sonar  and  control 

modes  to  execute  a  torpedo-tube  approach.  These  arc  primarily  tactical-level  is.'^iies  and 
involved  path  planning  and  command  generation. 
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Most  strategic-level  research  relevant  to  this  thesis  was  far  enough  removed  even 
from  the  tactical  level  issues  that  it  could  be  conducted  in  parallel  almost  from  the 
beginning.  The  major  goal  of  strategic  level  research  was  to  simplify  the  mission- 
generation  process  to  such  a  degree  that  a  user  did  not  have  to  be  a  Phoenix  expert  to  be 
able  to  program  a  complex  mission.  Specification  of  location  and  type  of  recovery  is  one 
aspect  of  this  area  of  research.  The  most  significant  result  of  this  research  was  a  mission¬ 
planning  expert  system  for  automatic  generation  of  Phoenix  missions.  Much  of  this  joint 
research  is  documented  in  [Leonhardt  96]  with  more  detailed  coverage  later  in  this  thesis. 

D.  IMPLEMENTATION  AND  TESTING  IN  THE  REAL  WORLD 

Real-world  implementation  and  testing  occ  red  in  two  parts:  implementation  and 
tc.siing  on  the  vehicle’s  hardware  and  verification  ■  irtual  world  results.  Because  Phoenix 
does  not  actually  use  physical  .sensors  and  controls  when  missions  are  conducted  in  the 
virtual  world,  it  is  neces.sary'  to  verify  the  software’s  interface  with  the  actual  vehicle 
hardware  before  conducting  in-water  tests.  Physical  control  of  the  sonars,  reading  and 
filtering  of  sensor  data,  and  polarity  and  response  of  control  actuators  all  must  be  verified 
by  bench  tests  and  (to  a  lesser  degree)  by  in-  water  te.sts.  A  more  detailed  discussion  of  this 
topic  can  be  found  in  [Bums  96|. 

Real-world  verification  of  UVW  results  is  conducted  in  ntuch  the  same  manner  as 
the  initial  implementation.  Initial  tests  were  intended  to  confirm  the  sonar  control  and 
Uacking  behaviors,  with  subsequent  tests  verifying  the  station-keeping  behaviors.  Te.sting 
of  higher-level  behaviors  (including  the  full  torpedo  tube  recovery)  were  contingent  upon 
successful  low-level  behavior  te.sts.  A  detailed  di.scu.ssion  of  real- world  and  virtual-world 
test  results  is  contained  in  Clhaptcr  VII  of  .  lis  thesis. 
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E.  SUMMARY 


This  chapter  provides  an  overview  on  how  this  research  was  conducted.  The  U  VW 
was  of  key  importance  to  the  conduct  of  this  research.  In  order  to  facilitate  its  use,  a  general 
sonar  model  was  implemented  to  simulate  the  response  of  the  ST725  and  STIOOO  sonars. 
The  sonai'  model  was  implemented  by  importing  a  copy  of  the  scene  into  the  UVW’s 
dynamics  module  using  the  Open  Inventor  ray-pick  function  to  simulate  the  sonar  beam. 
Visualization  was  also  implemented  for  botli  sonars  in  the  viewer  portion  of  the  UVW. 

Subsequent  to  implementation  of  a  general  sonar  model  for  the  ST725  and  STIOOO 
sonars,  the  UVW  was  used  as  the  primary  implementation  and  testing  tool.  With  the 
exception  of  hardware  interfacing,  all  aspects  of  tliis  research  were  implemented  and  tested 
in  the  UVW  prior  to  attempting  real-world  tests.  Implementation  of  Phoenix  software  was 
conducted  primarily  in  a  bottom-up  fashion  with  low  level  functionality  being 
inrplemented  and  tested  prior  to  implementing  higher  level  behaviors.  Once  functionality 
was  tested  in  the  UVW,  real-world  tests  were  conducted  to  ensme  proper  hardware 
utilization  and  response  and  verify  UVW  results. 

The  following  chapter  describes  behaviors  implemented  at  the  execution  level  of 
Phoenix  software  architecture  to  support  recovery.  Implemented  behaviors  include  vaidous 
sonar  control  modes  that  can  be  used  to  locate  and  track  objects  in  Phoenix  environment,  a 
vehicle  contiol  mode  for  .stationkeeping  relative  to  an  object  being  tracked,  and  a  vehicle 
control  mode  for  ptiysical  entry  into  a  recovery  tube. 
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IV.  EXECUTION  LEVEL  IMPLEMENTATION 

A.  iriTRODLICTION 

I'his  chapter  discusses  implementation  of  behaviors  at  the  execution  level  that  are 
required  during  recovery.  Since  the  execution  level  is  primarily  responsible  for  low-level 
pliysical  control  and  iiiteifucing  with  the  vehicle’s  hardware,  behaviors  implemented  at  this 
level  must  be  fairly  simple  but  robust.  It  is  the  responsibility  of  the  tactical  level  to  invoke 
execution-level  behaviors  to  carry  out  tactics  that  will  (in  turn)  aci:oinplish  still  highei-level 
goals  specified  by  the  strategic  level. 

'I'he  next  section  in  this  chapter  details  implementatiou  of  .S'l'lOOO  somir  control 
which  is  built  upon  the  primitive  behaviors  de.scribcd  in  [Healey  ‘M|.  Specific  sonar 
control  modes  implemented  include  a  manual  contr  ol  mode,  a  forward- looking-scan  mode 
for  collision  avoidance,  a  target  search  mode  for  locating  targets  specified  by  the  lactiiial 
levi  I,  and  two  target  tracking  modes  for  u.se  during  station  keeping.  'I'he  third  section 
covers  implementatiou  of  vehicle  control  modes  for  staticn  keeping  relative  to  a  tar’get. 
binally,  implementation  of  a  vehicle  control  mode  for  entry  into  the  recovery  tube  is 
presented  in  detail. 

ft.  SONAK  HKlIA  VlOK 

i.  Manual  (  ontrol 

The  simplest  anil  most  obvious  Sd'lOOO  behavior  is  “manual”  control,  I'his  control 
mode  respoiuis  to  commands  liom  the  tactical  level  by  po.sitioiiing  the  .sonar  at  specified 
relative  ucumigs.  IVlanual  conlioi  piovides  a  means  for  the  tactical  level  to  completely 
control  the  openttiou  of  the  S'l'lOOO  .sottar  for  target  cla.ssifictttion.  obshtcle  detection  or 
other  opertttions  that  may  be  more  suited  tt)  the  .S'l'lOOO  than  lheS'172S.  in  addition  manual 
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control  is  used  during  the  final  phase  of  the  recovery  to  position  the  STKHK)  for  distance 
keeping  from  the  side  of  the  tube. 

The  current  STIOOO  bearing  s  maintained  at  the  execution  level.  When  a  bearing 
is  commanded,  the  STIOOO  is  stepped  towards  the  commanded  bearing  at  a  rate  of  one  step 
per  closed  loop  cycle.  Step  size  for  the  STIOOO  can  be  set  to  0.^^,  1 ,8  or  3.6  degrees  (a  step 
size  of  0.9  degrees  was  used  during  this  research).  Once  the  commanded  bearing  is 
reached,  the  sonar  w'ill  remain  at  this  relative  bearing  until  a  new  eonunand  is  received  or 
until  the  eontiol  mode  is  changed. 

When  under  manual  control  the  .sonar  will  ping  once  per  closed  loop  cycle  (six  or 
10  hertz)  wliethor  it  is  being  stepped  towards  the  commanded  bearing  oi  has  already 
reached  it.  This  behavior  makes  it  possible  for  the  tactical  level  to  control  a  manual  sector 
scan  simply  by  alternating  bearing  comnninds  between  the  edges  of  the  scan  sector.  Otlier 
fairly  robust  behaviors  can  be  similarly  controlled  by  the  tactical  level. 

( 'ommanded  sonar  bearing  is  convcticd  to  an  achievable  bearing  an  1  normalized  to 
a  range  of  [O  ..  .^60)  degrees  beiore  the  sonar  is  actually  scanned.  This  prevents  the  sontir 
from  stepihng  back  and  I'orth  across  a  ettmmanded  irearing  and  simplifies  determination  of 
scan  direction,  As  an  e.xamjtle  .suppose  a  bearing  command  of  - 10,0  degrees  is  received  by 
the  execution  level.  Using  a  step  size  of  0.9  degrees  and  .starting^  from  0.0  degrees,  the  sonar’ 
is  callable  ol  being  scanned  to  -9.9  degrees  or  -10.8  degrees,  but  not  10  degrees  extictly. 
riu'  commanded  bearing  is  therefore  converted  to  9.9  degrees  (since  that  legal  value  is 
closest  to  tlie  actual  commanded  bearing).  The  roundoff  reliction  is  defined  as 


riniiifiii  riinfiiit'il 


(Tq. 9) 


.Since  tlie  current  Sd'lOOO  lieariiig  is  maintained  in  the  range  of  |0  ..  360)  degiees, 
the  commanded  bearing  is  normalized  to  .3.60. 1  degrees  .so  that  the  commanded  and  cm  rent 


bearings  can  be  compared.  The  difference  between  the  commanded  bearing  and  cunent 
bearing  is  then  normalized  to  a  range  of  •  1 80  degrees  to  1 80  degrees.  If  this  difference  is 
greater  than  zero,  the  sonar  is  scanned  to  the  right;  if  it  is  less  than  zero,  the  .sonar  is  scanned 
to  the  left. 

2.  Forward  Scan 

For  many  Phoenix  evolutions,  particularly  transits  in  tlight  mode,  it  is  desirable  to 
u.se  the  STIOOO  in  a  forward-looking  scan  pattern.  This  sonar  operating  mode  has  been 
implemented  and  is  automatically  initiated  whenever  the  execution  level  receives  a 
comtnand  that  will  require  any  of  the  following  vehicle  control  inodes:  hover  control, 
w'aypoint  control,  open-loop  lateral  control,  oiren-loop  rotate  control  or  any  other  kind  of 
thruster  conuol. 

f’his  forward  scan  pattern  is  primarily  used  for  used  for  imminent  eollisioti 
detection  and  will  trigger  a  reflexive  mission  abort  as  de.scribed  in  |  Burns  %]  if  tin  obshicle 
is  detected  within  a  certain  range.  The  scan  sector  is  of  constiint  .size  :tnd  is  centered  tibont 
zero  degrees  relative  to  the  heading  of  the  Al  IV,  The  default  sector  size  is  .^(i  degrees  but 
can  be  arbitrarily  changed  using  mission  script  commands  which  are  listed  in  Appendix  B 

.1.  rarget  Search 

.Since  the  STIOOO  is  to  be  used  for  precision  control  relative  to  objects  near /'/ior'/fu, 
sonar-control  modes  me  necessaiy  for  locating  and  tracking  those  objects.  I'he 
implementation  of  the  STIOOO  target-si.  ch  mode  makes  two  significant  assumptions:  the 
target  has  been  identified  by  the  tactical  level,  and  the  target  can  be  discriminated  from 
background  objects  based  on  range.  The  first  assumption  relates  to  the  tasks  assigned  to 
the  diflercnt  levels  of  KBM,  while  the  second  relates  to  tlie,  type  of  environment  expected 
during  statittn  kcepiirg  relative  to  a  sonar  target. 


v-  first  assumption  (regarding  target  idenr’t'’eation)  lelates  to  sucecssfirl 
implerncniatioii  of  lactical  ievel  responsibilities  including  interpretation  of  sonar  data  and 
classification  of  objects.  Initial  location  of  objects  by  the  tactical  level  can  rely  on  data 
from  the  S'r72.5,  ifie  STl  ()()()  (probably  using  manual  control  by  the  tactical  level  )  or  both. 
Real  -time  object  classification  using  sonar  has  been  the  subject  of  previous  Phoenix 
research  and  continues  to  Ire  an  area  of  siginficant  interest  [Brutzman  92,  Campbell  96). 
Once  an  object  lias  been  identified  by  the  tactical  level,  the  STIOOO  taig.ct-search  mode  uses 
the  approximate  range  and  bearing  information  to  find  it. 

The  second  assumption  (regarding  target  discrimination)  is  that  the  target  is  in  a 
relatively  open  ,'uea.  This  assumption  allows  the  target  .search  to  rely  only  on  the  expected 
range  and  bearing  to  tlie  target  lathei  than  heuristics  concerning  the  type  of  target.  The 
advantage  of  tins  approacli  is  if,  generality.  Use  of  heuristics  for  target  identification 
as,sunies  that  the  vehicle  has  a  certain  amount  of  knowledge  concerning  tht  characteristics 
of  the  target  [Marco  96 1.  This  knowledge  must  be  present  for  every  type  of  object  that  is 
to  be  identified.  Basing  target  identification  strictly  on  range  and  bearing  information  does 
not  require  knowledge,  about  the  characteristics  of  the  largei  and  can  theref  re  be  used  to 
locate  any  type  of  object.  I’he  disadvantage  is  that  it  is  possible  to  incorrect,  y  identify  a 
target  when  operating  in  a  cluttered  environment.  An  uncloUeied  environment  is  a  good 
assumption  for  an  at-sea  docking  staiion.  On  tlic  other  hand  torpedo  tubes  are  a  themselves 
a  highly  ckuiered  environment.  Kven  in  this  case,  however,  successful  maneuvering  in  an 
uncluttered  environment  is  an  essential  prerequisite  to  attempting  more  difficult 
environments. 

'I'lie  metliod  used  to  determine  .scan  direction  tor  a  target  search  is  the  same  as  liuit 
used  for  manual  control,  bach  sonar  return  during  the  .search  is  examined  to  determine  if 
die  desired  object  has  been  detected.  .Sonar  range  and  bearing  information  is  used  to 
determine  carth-fi.sed  coordinates.  The  bearing  and  range  from  tlie  AU  V  to  tiic  object  can 


then  be  ciitnputeci  and  compared  in  the  expected  range  and  bearing  to  the  target.  In  order 
to  simplify  calculations,  AIJV  pitch  is  assumed  to  be  negligible.  The  position  of  the 
Sd'lOOO  sonar  head  in  world  coordinates  is  then  given  by 
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(Eq.  10) 


where  (xi,,  v,, )  is  the  position  of  the  ST  1000  sonar  head  in  .AUV  body  coordinates  and  //. 
is  the  two-dimensional  version  of  Equation  4  and  is  given  by  {Kanayama  961 
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Once  tne  global  position  of  the  sonar  head  has  been  determined,  the  range  and  bearing  are 
converted  to  world  coordinates  usinc 

(Eq.  12) 

where  v  is  the  ALIV  heading.  is  the  STIOOO  relative  bearing  and  A’  is  the  S'l'l ()()() 

range.  The  range  from  the  AIJV  centroid  to  the  target  is  then  computed  as 

R  =  /(.x-x,  13) 

and  bearing  Eom  the  AIJV  to  the  target  is  computed  as 

(1  =  atanty,  y,  x,  x)  (E  ).  14) 

where.  atan(y„r)  is  a  function  returning  an  angle  in  the  range  of  10  ..  360)degrees.  Equations 
i  0  through  1 .6  are  equivalent  to  the  equations  defined  in  [Marco  96aj  to  calculate  the 
location  of  Phoenix  relative  io  a  cylinder.  This  relationship  between  sonar  range  and 
bearing  and  AUV  range  and  bearing  is  shown  in  Eigure  16. 

Once  the  laugc  and  bearing  from  the  AIJV  to  the  sonar  target  have  been  cuinyiuted. 
they  arc  compaicd  to  the  expected  range  and  bearing  to  the  (f  sired  suiuu  target  as  a 
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discriminator.  If  the  ntea.sured  range  i.s  within  five  feet  of  the  expected  range  and  the 
measured  be:iring  is  within  15  degrees  of  the  expected  bearing,  the  return  is  assumed  to  be 
part  of  the  desired  target.  Once  these  conditions  are  met,  the  sonar-control  mode  is 
automatically  switched  to  target  track  or  taiget-edge  track.  Which  mode  to  select  is 
explicitly  specified  by  the  mission-script  command  that  initiated  the  target  search. 


4.  Torpct  Traj'kiiiK 
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Once  the  desired  son;u  target  has  been  located,  a  sonar  mode  is  reiiuircd  to  maintain 
contact  with  that  target.  'I’wo  such  modes  have  been  iiriplemented:  a  full  target-track  mode 
and  a  target-  edge-track  mode.  When  using  the  full  target-uack  mode  the  sonai  continually 


sweeps  back  and  foitli  across  the  entire  sonar  target,  updating  target  range  and  bearing  only 
alter  the  sonar  has  scanned  off  the  edge  of  the  target. 

As  the  sonar  tracks  across  the  target,  each  range  is  compared  witli  the  previous 
range.  If  the  range  is  within  five  feet  of  the  previous  range,  it  is  assumed  to  be  part  of  the 
same,  target,  Becau.se  of  the  somewhat  unreliable  nature  of  sonar  data,  a  return  that  does 
not  meet  the  range  criteria  does  not  necessarily  mean  that  the  sonar  has  scanned  off  the  edge 
of  the  target.  1  o  account  for  anomalous  sonar  returns.  th.vee  consecutive  off-target  returns 
are  required  to  initiate  a  sonar-scan  reversal  along  with  taiget  range  and  bearing  update. 

When  the  sonar  conu  oller  deteimines  that  the  .sonar  has  been  scanned  past  the  edge 
of  the  target,  range  and  bearing  estimates  are  updated  using  averaging.  As  'he  sonar  h  acks 
the  target  a  range  accumulator  is  maintained.  Anomalous  returns  that  cannot  be  included 
in  tlie  target  are  not  included  in  the  range  accumulator.  Sonar  range  to  the  target  is  simply 
tile  average  of  the  valid  returns  from  the  previous  sweep,  iii  addition  to  die  range 
accumulator,  the  sonar  eoruroller  maintains  the  initial  bearing  of  the  cuirent  scan.  I'lic 
bearing  to  tlie  target  is  then  computed  as  the  bisector  of  the  starting  and  ending  bearings  ol' 
the  cuirent  scan.  Once  the  range  and  bearing  of  die  target  from  the  sonar  have  been 
determined,  tai'get  range  and  bearing  from  the  AUV  are  computed  using  liquations  U 
through  14. 

An  illustration  of  the  tiuget-track  geometry  is  shown  in  Figure  17.  The  target-track 
control  mode  implementation  is  similar  to  tlie  sonar  control  de.sciibcd  in  |  Marco  96aJ  and 
differs  significantly  only  in  two  rcgard.s.  First,  sector  width  is  not  fixed  but  is  determined 
by  the  size  of  the  target.  Second,  a.s  with  initial  target  detection,  target  identification  is 
based  on  range  and  bearing  rather  than  target  characteristics. 
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Figure  17:  Sonar  Full  Target-Track  Mode  Geometry. 

In  addition  to  providing  target  range  and  bear  ing  information,  the  target-track 
control  mode  ha.s  one  more  benefit.  The  range  arrd  bearing  data  obtained  during  the  full 
target  track  eontain.s  a  large  amount  of  infoi'mation  about  a  single  object  in  the  world.  Since 
S  T  100(1  r;iri,ge  and  bearing  are  prut  of  the  .state-vector,  this  data  can  be  (.miieuneiitly 
analyzerl  by  the  tactical  level  sonar  module  to  aid  in  object  classification. 

5.  Target  Edge  Tracking 


Maintaining  sonar  contact  with  the  target  by  scanning  across  the  entire  target  has 
one  significant  disadvantage;  the  lirrre  period  between  successive  range  and  bearing 
updates  can  be  as  much  as  ten  .seconds  j  Marco  9bal.  'This  slow  update  rate  can  lead  to 
skiggi  sii  AI JV  response  and  navigational  inaccuracy  because  of  errors  in  the  onboard 
hydrodynamics  maihemarical  model  de.scribed  in  the  following  section.  In  order  to 
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increase  the  target  data  update  rate,  a  second  target-tracking  sonar  mode  has  been 
implemented.  Rather  than  .scanning  across  an  entire  object,  this  control  mode  altempcs  to 
track  only  the  edge  of  the  target. 

Once  a  target  has  been  located  using  the  target- search  control  mode,  the  sonar  is 
scanned  left  or  right  until  it  scans  past  the  edge  cf  the  object.  The  target’s  edge  is  identified 
using  the  same  algorithm  as  full  target  tracking.  Again,  once  the  edge  is  found  the  scan 
direction  is  reversed.  Rather  than  tracking  across  the  target  all  the  way  to  the  opposing 
edge,  however,  the  .sonai  is  scanned  only  until  three  returns  that  can  be  identified  as  part  of 
the  target  have  been  received.  Returns  are  identified  as  pail  of  the  target  in  the  same 
manner  as  the  l  ull  taiget-ti'ack  mode.  Once  three  tai  get  returns  have  been  received,  scan 
direction  is  rever.scd.  The  edge-track  algoritlim  can  be  summarized  as  a  loop  consisting  of 
four  steps;  scan  off  of  the  target,  rever.se  scan  direction,  scan  onto  tlie  target  and  reverse 
scan  direction.  The  smaller  scan  sector  width  results  in  target  range  and  bearing  update, 
rates  that  are  much  faster  than  those  for  full  taiget  tracking. 

Since  tlic  soiiai'  does  not  track  across  the  entire  target,  average  sonar  range  and 
bearing  to  the  target's  center  cannot  be  computed.  Instead,  range  and  bear  ing  are  computed 
to  the  edge  being  tracked.  Range  computation  is  accomplished  in  the  same  manner  as  with 
the  full  target  track.  Normally  the  range  computed  will  be  the  average  of  three  Individual 
sonar  ranges.  Depending  on  AIJV  motion  during  the  scan,  however,  the  actual  number  of 
returns  ineluded  in  tfie  average  may  vary.  The  sonar  bearing  of  the  edge  is  simply  the  first 
bearing  from  which  a  valid  return  was  received  if  the  sonar  is  being  scanned  onto  the  target, 
or  tlic  last  bearing  from  wliicli  a  valid  ictum  was  received  if  the  sonar  is  being  scanned  oft 
of  tile  target.  Again,  once  the  range  and  bearing  liom  llr  sonar  have  been  detenriiiied, 
range  and  lieaiingfroni  the  AU'V  are  dcterimiicd  using  liipiations  H)  tlirough  14.  ( ieumeliy 
of  the  target  cdgc-tiack  mode  is  sliown  in  b’igiiie  IX. 
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The  target  edge  used  for  tracking  is  determined  by  the  direction  that  the  sonar  is 
scanned  immediately  after  target  detection.  If  the  sonar  is  .scanned  to  the  right,  the  right 
edge  is  used;  if  sonar  is  scanned  left,  the  left  edge  is  u.sed.  The  sonar  .scan  direction  is  based 
upon  the  direction  that  the  AUV  will  need  to  move  to  reach  the  commanded  range  and 
bearing.  If  the  current  bearing  to  the  target  is  less  than  the  commanded  bearing,  the  AUV 
will  need  to  ntove  left,  In  this  case  the  sonar  is  .scanned  to  the  left  following  target 
detection.  Choosing  the  tracking  edge  in  this  manner  is  intended  to  prevent  the  .All  V  from 
colliding  with  large  targets  because  the  wrong  (,i.e.  far)  edge  was  u.sed. 


Figure  *8:  Sonar  Target  Edge  Track  Mode  Geometry. 


As  stated  previously  the  major  advantage  of  the  target-edge- track  control  mode  is 
an  increase  in  the  range/b'  -aring  update  rate  over  that  of  the  target-track  mode.  Target- 
edge -track  has  the  disadvantage  of  not  obtaining  as  much  information  about  the  target  as 


the  full  target-track.  An  inability  to  compute  the  center  point  of  the  target  is  one  example 
of  this.  Conceivably  this  disadvantage  might  be  eliminated  by  simultaneous  target-edge¬ 
tracking  and  target-tracking  using  both  the  ST725  and  ST  1000  sonars. 

C.  STATION  KEEPING 

1.  Station  Keeping  Commands 

Two  commands  v/ere  added  to  the  execution  level  command  language  defined  in 
[Bi  utzman  04 1  to  control  station  keeping  relative  to  a  .sonar  target:  target-station  and  target  • 
edge-station.  These  two  commands  correspond  to  the  two  target- tracking  sonar  modes: 
target  track  and  target-edge-tiack  respectively.  Both  commands  have  tlie  same  parameters 
and  are  imerpreted  in  the  same  way  by  the  execution  level.  The  sole  difference  between 
these  two  commands  is  the  .sonar  control  tnodc  tJtat  will  be  initialed.  Format  and  parameter 
syntax  details  for  both  of  these  commands  can  be  found  in  Appendix  B. 

Station  keeping  comtrumds  can  have  two,  three,  four,  or  five  parameters.  4’he  four 
and  five-parameter  versions  are  used  to  initiate  a  target  sciu'eh  prior  to  station  keeping, 
while  tlie  two  and  three-parameter  versions  arc  u.sed  to  change  commanded  range  and 
bearing  from  a  target  already  being  tracked  for  station  keeping.  Tlie  two-parameter 
command  specifies  a  commanded  range  and  bearing,  while  tlie  optional  third  pai  ameter  can 
be  added  to  specify  a  commanded  vehicle  heading.  If  no  iliird  parameter  is  present,  AIJ  V 
heading  will  continuously  point  directly  at  ihc  target.  The  four-parameter  command 
s[)ecifie.s  an  estimated  range  and  beai  ing  to  the  target  for  use  during  the  target  .search  and  a 
commanded  range  and  bearing  for  station  keeping.  The  fifth  parameter  specifies  a 
commanded  vehicle  heading.  The  difference  between  the  comiriai'ded  bearing  and  the 
estimated  current  bearing  .specified  in  the  command  is  used  to  determine  which  edge  will 
be  used  if  targct-edge-trackiiig  is  called  for. 
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Since  execution-level  target-track  and  target-edge-track  sonar  modes  are  initiated 
automatically  by  the  target-search  sonar  mode,  it  is  impossible  to  switch  between  target- 
track  and  target-edge-track  without  initiating  a  new  target  search  (i.e.  by  using  the  target- 
station  or  target- edge-station  command  with  four  or  five  parameters).  If  the  AUV  is 
maintaining  station  relative  to  a  target’s  edge  and  a  target-station  command  is  received,  the 
target -station  command  will  be  interpreted  as  an  edge-.station  command.  Similarly,  an 
edge-station  command  will  be  interpreted  as  a  target -.station  command  as  appropriate.  In 
addition,  if  a  two  or  tliree -parameter  .station  keeping  command  is  received  while  the  sonar 
is  not  in  target-track  or  target -edge-track  mode,  the  station  keeping  command  will  be 
ignored. 


2.  Commanded  AIJV  Position  and  Control 

The  implementation  of  Phoenix'  target  control  involves  the  translation  of  the 
commanded  rairge  and  bearing  to  global  (x,  y)  coordinates.  Basing  stotion-keeping  control 
laws  on  global  coordinates  allows  the  use  of  control  laws  similar  to  those  used  for  hover 
control  as  descriheti  in  IHums  Hach  time  the  .sonar  control  updates  the  range  and 
bearing  to  the  target,  the  global  position  of  the  commanded  .station  is  computed  as 


I  'iinmaiXil 
^  '  I  nnxmunil 


I  \  P  t’OS  {  +  C<>S(  ("i, +  ISO  .-((ni/.KiM// 

'  v-t  Sindh  futrrnt  1  .-tlH-iJH  fj/lj  ' 


(bq.  Lb) 


where  |h.,„,,.„r  and  (I,  are  the  current  and  eomrnand  bearings  from  the  All  V  to  the 


target  and  and  are  the  current  and  commanded  ranges  from  the  AUV  to  the 

target.  It  is  important  to  note  that  eontrol  is  ba.sed  on  relative  range  and  bearing  between 
the  AUV  and  target,  despite  the  conversion  to  world  coordinates. 


The  direction  in  which  the  AU  V  must  move  to  achieve  the  commanded  position  is 


computed  as 


while  the  distance  that  the  AUV  needs  to  travel  is  computed  as 


~  ^command)' +  iy  - 


y  cunimattd) 


The  foiWtird  and  lateral  distances  relative  to  the  AUV  ai'e  computed  as 

=  £/  ■  COS(r- V) 


(Eq.  16) 


(Eq.  17) 


(Eq.  18) 


-  track  ^  \|/ ) 


(Eq. 19) 


re.spectively.  The  computed  values  for  and  are  used  witli  vj/.  u  and  an 

estimate  of  ocean  cunent  in  the  form  )  in  PD  conPol  laws  for  stern  propeller 

I  pm,  and  bow  and  stern  lateral  thruster  voltage.  The  .stern  propeller  ipm  control  law  is 


where 


rpm  =  - /Vo/;,, 


(Eq. 20) 


prop  -  hovel  ^on  intck 


7  ’’OPrurrem  ^itrap  rurrcniO^currmr  '  eOS(\p)  +  y^urrrnl  '  *>'n(y)) 


(Eq.21) 
(Eq. 22) 


(Eq.  23) 
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The  bow  and  stern  lateral  thruster  voltage  control  law,;  are 


(Rq. 24 1 

(Hq. 23) 

(Eq.  26) 
(Eq. 27) 
(Eq.  28) 

(Eq. 29) 


Coirs  tant 

Value 

llniLs 

hn\,r 

20P.t) 

ipiii  /  It 

^pn>p  iurr,'ni 

Wif )().() 

ntm-socs  /  fi 

24(K).() 

ipm-.SL'cs  /  n 

^ihiustvr  y 

().2(K) 

Volts  /  ilcgices 

^thiust^r  -r 

2.0 

Volts-sccs  /  degrees 

^ihrusi^r  huvnr 

3.3333 

Volts  /  It 

^.swuy 

20.0 

Volts-sccs  /  ft 

^ShrusU'T  -furr^nt 

40.0 

Volts  sec.s  /  ft 

'Table  3.  Station  Keeping  PD  Control  Law  Constants. 


and 


wlierc 


^  =  -  nn  r  Thruster, +  Thrustet  .„^.^^~rhru.ucr,., 

^  ,u-rn  =  Thruster, Thru.uei  ,.,„^,  +  Thru.sl(f  -  Thruster,.,,^, 

Thruster, „„  —  “  ~  command)  ^ 

I  hr  uster 

Thruster,,,,,,  =  „,„,v 


and 


T  hr  lister  ^-urnml^'^rurr^m  SinlXI/)  ^  cut  rt>  nt  '  rOS\|/) 

Values  and  units  for  PD  control  constants  arc  listed  in  Tabic  3. 


3.  ATJV  Tracking 

Because  ol'  the  speed  and  asynchronous  nature  oT  sonat  tni.sed  target-position 
update  rate,  a  method  is  required  for  compiiling  t’hoenix  i)usition  and  velocity  between 


updates.  Over  the  long  term  the  best  solution  is  probably  the  ineorporatiou  ol  an  iuei  tial 
measuremenl  unit  (IMU)  capable  of  providing  position  updates  in  real  lime  I  Mcf  ihee  b.'i, 
Bachmann  96  ] ,  For  the  present  however,  Phoenix  does  not  htive  instal  led  hardwtire  that  can 
provide  real  time  navigational  information.  As  a  short-term  solution,  a  simple 
mathematical  model  based  on  contiol  inputs  has  been  developed  and  incorporated  to 
estimate  Phoenix  position  and  velocity  between  target  updates  1  Marco  96a|. 

d’he  mathematical  model  is  a  three  DOF  dead  reckoning  model  that  includes  drag, 
added  mass  and  steady  state  surge.  Because  Phoenix  hardware  includes  a  directional  gyro 
that  directly  jirovides  yaw  and  indirectly  [irovides  yaw  cate  (by  differentiation  of  yaw),  only 
the  surge  and  sway  etiuation;;  of  motion  from  [Marco  dpal  are  used.  The  surge  and  sway 
e(.|u;itions  of  motion  are  [Marco  9Pa[ 

A-t,a(C)  +  hpu,/)i//(0l  =  -io.rdtllr.tol  (Fq,  d(l) 

/V/pHt)  +  hvV{t)|v(f)|  =  nyV,.i,{l}\v,,i,(n\  X  (liq.  31 ) 

where  At,  and  ate  the  sum  of  mass  and  added  mass  in  the  x  and  y  body  axes,  b,  and  />, 
are  .square-law  damping  coefficients,  u,  and  are  voltage-to-force  coefficients  and  \\{i)  . 

and  ‘tfc  terms  for  the  voltage  tipplied  to  the  projiellers.  bow  lateral  thruster 

and  stern  lateral  tliiustei  .  More  specifically  a.symmeuic  voltage  to  the  aft  piopellers  is 
accounted  for  u.sing  [Marco  96a[ 

V,  '  ''ir,,(r)|  +  iv,(r)[r,,(r)[ 


v,(/)|v,(r) 


(lup  32) 


where  r,,|r)  and  v'.gq  are.  the  voltages  applied  to  the  left  :ind  rigdit  pidpellers.  Known 
ocean  current  is  accounted  foi  when  converting  body  fixetl  rates  to  vvoi  hi  rates: 


(*> 


m) 


'  Alt) 

eril 

1:= 

cii.s(\|/)  ,siii(\|/) 

M(f) 

.  vlt) 

1 

siii(v|/)  i:os(\|/) 

,  i’(r)  , 

(Hq.  3d) 
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Values  and  units  of  constants  used  in  the  niathcrnatical  model  aie  sho  wn  in  Table  4. 


Constant 

Value 

Units 

'2l4.2n 

Ki» 

W, 

.VtO.'/t) 

Kg 

(A.KO 

Kg/m 

HI.*!  .41) 

Kg.  /  m 

t).0.S6 

N  /  Voles- 

O.Olk 

N  /  VolLs- 

Table  4.  Mathenialieal  Model  Constants  lM;irco%a]. 

While  this  matJtematieal  model  is  simple  enough  to  calculate  in  real  time  and 
at'curatc  enough  to  compute  reasonable  navigational  values,  it  is  nut  peifect  |Mari  o  '^lba|. 
Target  ptrsition  updates  based  on  sonai'  data  remain  the  most  accurate  means  of  calculating 
the  location  of  the  AIJ  V  relative  to  a  target.  Since  the  purpose  of  the  mathematical  model 
is  to  maintain  AUV  position  and  velocity  information  between  sonar-  based  position 
updates,  it  is  reset  each  time  a  po.sition  update  is  received.  In  this  way  incremental  eirors 
in  the  mathematical  model  are  not  permitted  to  build  up  to  unacceptable  values  over  time. 

An  important  area  foi  future  work,  remains  validation  of  AUV  hydrodynamics 
coefficients.  .Since  a  general  ix DOb'  hydrodynamics  virtual  world  moriel  for  Phoenix  can 
run  in  real  time,  more  accurate  omboard  dead  reckoning  is  po.s.sible  |Brut/.man  b4|. 

1).  FINAL  RKCOVKRY  CONTROL 

The  final  addition  to  the  execution  level  in  .support  of  this  re.searcb  was  the 
implementation  r)f  a  control  mode  to  drive  Phoenix  into  the  recovery  tube.  As  with  the. 
laige.t  l lacking,  sonar  modes  and  station  keeping  ’-ontiol  mode,  the  recovery  coniiol  mode 
assumes  that  the  position,  orientation  and  si/i‘  of  the  rccoveiy  lube  has  been  deUa  iiiined  by 
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the  tactical  level.  The  goal  of  the  recovery  control  mode  is  to  drive  Phoenix  a  specified 
distance  into  a  tube  v  '  he  maintaining  adequate  clearance  from  both  sides. 

Recovery  coiiuol  is  initiated  by  the  tactical  level  once  Phoenix  is  directly  in  front 
of  the  recovery  tube  with  its  nose  just  inside.  Upon  recovery  initiatioti  the  STKKK)  sonar 
is  switched  to  manual  control  and  slews  relative  7.5  degrees  left.  At  the  same  time  the 
tactical  level  s''’uir  manager  slews  the  S'1’72.5  sonar  relative  75  degrees  to  the  right.  Phoenix 
]tusitioning  relative  to  tlic  tube  at  this  point  is  shown  in  h'igiire  Id. 


l-'igure  Id:  ALIV  and  Recovery  'I'ube  Layout  at  Recovery  Control  Initiation. 


PD  control  laws  arc  then  u.scd  to  drive  Phoenix  into  the  tube.  The  mathematical 
model  described  in  the  previous  section  is  used  to  estimate  the  distance  travelled  into  the 
tube  while  the  STKKK)  and  .S'r725  .sonars  are  used  to  keep  Phoenix  in  the  center  of  the  tube 
I'lie  control  law  for  the  aft  propellers  is 

V, . .  cn.styM  v„ . .  .siiiOi/|)  (bq.  14) 

where  il  is  the  remaining  distance  into  the  tube  as  computed  by  tile  mathematical  model. 
The  control  laws  for  the  bow  and  stern  lateral  tiirustcrs  aie 

fb,,.,  -  V7in(.vn7,„„  +  77ira.vn'/v„„„  / /i/H.v/fr,,, V7in<.vter,„,,„„  (Fti.  .T5) 

and 

^  r /7irH.vfcq„„^,,  77i/«.vtr';^,„„.,,  77(r«.vn-/-,.,„^,,„  (liq.  .lb) 

(it 


vvlifie  and  Thrustei ;irc  computed  using  Equations  26  and  29  respectively. 


Thrusipr^^^^^^,  r=  _,„„^(,A's7-7,sSm(75°)  A’vrioooSinl?^"))  (Eq.  d7) 

and 

Thrusier^^^.^j  =  ,,;«.'«7  iooosin(75°)  (Eq.  3«) 

where  and  RsT72i  STIOOO  and  ST725  sonar  ranges.  These  conhul  laws  are 

very  similar  to  Equations  20,  24  and  25,  differing  primarily  in  the  values  of  the  control 
constants  and  how  tlie  individual  teniis  are  computed.  Values  of  control  constants  are  listed 
in  Tal  '-=■  5. 


Constant 

Vatui- 

Units 

I- 

20'>.() 

rpin  /  ft 

^prop  -rnr^t* 

6090,1) 

q>!n-.scc.s  /  fl 

^ prop  -  current 

6600.0 

qinti-sccs  /  ft 

^ihmxfcr-  4/ 

0.60 

Volts  /  clo.iin.'c.r 

^(hmstcr  •  r 

8.0 

VoUs-secs  /  degrees 

^'thruster  ronr,i' 

8.0 

Volts  /  ft 

1- 

‘'‘III'  ustcr  spe*.  d 

40.0 

Volts-secs  /  ft 

L 

’^'hrustet  current 

40.0 

Volts-sccs  /  ft 

L  _ 

Table  5.  Recovery  tlontrol  PD  (Tntrol  Constants. 

K.  sclvDd/'trv 

Thi.s  cluqiter  cov  ns  ifi.i’icinentation  of  features  at  ih.'*  •■'vecjium  level  of  Fhocnix 
(dl'.-arc  ''S  h:U:>.  ture  to  support  iTi.f.very  operations.  Robust  soii;ri  behaviors  arc 
ii.  uleme.'.ted  iiududing  iTh>.k;s  ■  suiijKu  t  manual  coiUrol.  hirward  scanning,  target  search 
tai  gct  haclcin;'  and  ne  gt-t-edge  irac’-  jug.  These  behaviors  aic  used  to  support  a  I'lim'nix 
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control  mode  capable  of  transiting  to  and  maintaining  a  commanded  range  and  bearing 
from  a  sonar  target.  PD  control  laws  are  u.sed  to  control  motion  relative  to  Lhe  target. 
Additionally,  because  of  the  asynchronous  target -position  update  rale,  a  mathetnatical 
model  was  developed  to  estimate  Phoenix  motion  between  sonar-based  target  updates. 
Finally,  a  control  mode  was  implemented  to  actually  drive  Phoenix  into  the  recovery  tube 
once  the  vehicle  obtains  a  position  immediately  in  front  of  the  tube.  This  control  mode  uses 
PD  control  laws  very  similar  to  those  used  for  station  keeping.  The  STKHK)  and  .ST72.S 
sonars  ate  used  to  ensure  clearance  from  the  sides  of  the  recovery  tube  throughout  the 
recovery  evolution  while  the  mathematical  model  is  used  to  estimate  forward  uavcl  into  the 
tube. 

The  following  chapter  of  this  thesis  covers  implementation  of  features  at  Phoenix' 
tactical  level  that  use  the  behaviors  described  in  this  chapter  to  control  recovery. 
Significant  issues  in  that  chapter  are  recovery  path  planning  and  command  generation.  In 
addition,  the  matl.ematical  structures  used  to  implement  path  planning  are  discussed. 


V.  TACTICAL  LEVEL  IMPLEMENTATION 


A.  INTRODUCTION 

One  of  the  primary  responsibilities  of  the  tactical  level  software  is  to  use  the  low- 
level  functionality  of  the  execution  level  in  such  a  way  as  to  accomplish  the  high-level 
goals  of  the  strategic  level.  Specifically,  this  chapter  will  cover  how  the  tactical  level  uses 
the  edge-tracking  sonar  behavior  and  the  station-keeping  control  available  at  the  execution 
level  to  support  vehicle  recovery  in  a  tube. 

I'he  second  responsibility  of  th<'  tactical  f  vel  that  directly  relates  to  recovery  is  the 
identification  and  localization  of  the  recovery  tube.  The  ST725  and  STIOOO  sonais  are  the 
primary  on-board  sensors  upon  which  this  task  depends.  Real-time  sonar  classification 
using  both  of  these  sonars  has  been  the  subject  of  other  re.scarch  and  is  not  directly 
addressed  here.  For  more  information  concerning  re.search  in  this  area  involving  Phoenix 
refer  to  [Brutzman  92]  [Campbell  96J  and  [Marco  96a].  A  major  a.ssumption  of  the 
research  of  this  thesis  is  that  the  recovery  tube  is  at  a  known  position  and  orientation. 

The  first  section  of  this  chapter  discusses  tactical  level  planning  of  the  recovery 
path.  The  mathematical  structures  used  to  implement  recovery  path  planning  are  covered 
as  well  as  the  pi  inning  algorithm.  The  other  major  topic  of  this  chapter  is  the  generation 
of  execution-level  commands  nece.ssary  for  following  the  planned  path, 

B.  RECOVERY  PATH  PLANNINC 

1.  Tran.sforniations 
a.  Description 

The  mathematical  structure  used  for  reem  ery  path  planning  is  called  a 
transformation.  A  transiormation  is  a  means  of  rcprc.scnting  an  object’s  position  and 
orientation  in  two  dimensions  (2D)  and  takes  the  form  of  a  state  vector  consisling  of  x 


position,  y  position  and  orientation.  The  coordinate  system  i  sed  for  a  transformation  is 
iirbitrary  and  can  represent  an  object’s  global  position  or  its  position  relat've  to  another 
object.  [Kanayama  96] 

In  addition  to  representing  an  object’s  position  and  orientation,  a 
transformation  can  be  used  to  represent  discrete  motions  with  2D  translations  and  rotations 
specified  in  body-fixed  coordinates.  Finally,  transformations  aje  useful  for  defining  lines 
and  circles.  Lines  are  specified  by  a  position  (which  can  be  any  point  on  the  line)  and  an 
orientation.  This  representation  of  a  line  is  convenient  for  path  planning  becju  se  it  includes 
a  direction  which  will  generally  represent  the  direction  of  motion  along  the  line.  The 
transformation  portion  of  a  circle  representation  consi.sts  of  a  point  on  the  circle  aud  the 
tangential  direction  of  the  circle  at  that  point.  A  circle  requires  a  fourth  term  representing 
the  cirvature  of  the  circle.  [K.  nayama  96]  Representation  of  lines  and  circles  using 
transfonnations  is  covered  in  more  detail  in  the  following  section. 

b.  Operations 

There  are  two  operations  defined  for  trairsfonnations:  composition  and 
inversion  [  Kanayama  96 1.  Composition  is  a  means  of  combining  two  transformations. 
Typically  the  first  transformation  reprc.sents  a  position  and  orientation,  and  the  second 
represents  a  motion  or  a  relative  position.  The  result  of  a  composition  is  the  final  global 
position  of  an  object  moved  from  a  position  (reprc.sented  by  the  first  transfoimation)  by  a 
change  in  position  and  orientation  (repre.sented  by  the  .second  transformation). 
Composition  is  defined  a:;  [Kanayama  96| 

.1,  a:,  jTi  h- c,  •  cos(I)|)  -  y  .  ■  sin(0|) 

y,  •  >■;.  =■  y,  A-.v,  ■  sin(0j  I +  >'_,•  c«.s{G|)  (Kq.  39) 

i  e,  J  1  e.  J  0,^  9^ 


This  definition  leads  to  the  definition  of  the  identity  transfomiation  (e ).  The  identity 
transformation  is  defined  as  (0,  0,  0)^  and  has  the  following  result  when  used  in 
compositions  [Kanayama  96]: 

(j  •  e  =  <'  •  </  =  q  (Ecj,  40) 

The  definition  of  e  leads  to  the  definition  of  the  inverse  function.  The  inverse  function  for 
transfonnations  is  defined  by  [Kanayama  96] 

q  •  q  '  =  q  '  •  q  -  c  (Eq.  41) 

and  for  q  -  (a,  v,  e)^  the  inverse,  q-' ,  is  given  by  the  equation  [Kanayama  96] 


<r' 


-V  cos(9)  -  V  •  sin(fl) 
A  ■  sin(0)  -  V  cos6 


(Eq.  42) 


Transformation  composition  can  also  be  used  to  generate  smooth 
trajectories  in  a  plane  by  composition  of  a  position  and  orientation  with  transformations 
representing  small  discrete  motions.  The  transfomiation  repre,senting  the  motion  is 
referred  to  as  a  circular  transformation.  A  circular  transformation 's  derived  using  the 
length  of  the  motion  ( l )  and  the  amount  of  change  in  orientation  over  that  length  ( a ).  The 
circular  transformation  i.s  computed  as  [Kanayama  96] 


Ay(/,a) 


siii(a)^ 

(X 

1  -  vosia)  j 

a 
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(Eq.43) 


For  linear  motions  (a  --  o  )  this  equation  is  undefined  but  can  be  approximated  using  a 
Taylor  expansion  resulting  in  [Kanayama  96] 


^qU-O.) 


( 1  ^  a’/  V.  +  aV5!  .  .)/ 
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A  series  of  small  discrete  motions  in  the  form  of  circular  transformations  is  capable  of 
approximating  a  continuous  smooth  path.  As  with  other  discrete  approximations  of 
continuous  functions,  smaller  circular  transformations  will  result  in  more  accurate  path 
approximation. 
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2.  Line  and  Circle  Tracking 
a.  Lines  and  Circles 

As  stated  in  the  previous  section,  lines  and  circles  can  he  specified  using 
transtorrnations.  Representation  of  a  line  takes  the  form  (x,  y,  0 )  where  (x,  y)  is  any  point 
on  the  line  and  G  is  the  orientation  of  the  line.  Since  any  point  on  the  line  can  be  used  in 
the  transformation  representing  a  hne,  an  infinite  number  ol  iransformations  are  possible 
for  representation  of  a  single  line.  For  this  reason  repre.sentation  of  lines  using 
transfomiations  is  probably  inappropriate  if  lines  are  to  be  compared.  Since  the  recovery 
path  planning  involved  in  this  research  docs  not  involve  comparison  of  different  paths,  the 
inability  to  compare  lines  for  equivalence  docs  not  pose  a  problem. 

Repre.sentation  of  circles  using  Iran.sformations  is  only  slij'htly  more 
complex  than  teprcseiitation  of  line,s.  Circle  representation  takes  the  form  (x,  y.  0,  k)’ 
where  (  ,v ,  -r )  i^i  ‘iny  point  on  the  edge  of  the  eirclc,  0  is  the  tangential  orientation  of  tiie 
circle  at  ( v ,  v  ),  and  k  is  the  curvature  of  the  i.avie  defined  a.s  I  Kanayama  96] 


where  v  is  the  distance  along  the  edge  of  the  circle.  Representation  of  circles  using 
transfoi  inati  ms  has  similar  advintages  and  ilisadvanlages  a.s  rcpie.sentaiion  e'f  lines.  The 
iiiosi  sigiiii'ieant  advantage  is  tliaf  by  specifying  a  tangential  orientation  it  is  possible  >■ , 
irnplii'itly  icpresent  the  direciion  of  (lesired  motion  w'hen  traveling  along  a  circular  patli 
(c.g.,  iiMiig  0  ).  Tlu.‘  disadvaiilagc  is  that  iheie  aie  an  infinite  immbor  of  Iraii.'dorinaiioii 
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representations  for  a  single  circle.  Again,  .since  recovery  path  planning  does  not  involve 
the  comparison  of  circles,  this  potential  disadvantage  is  not  relevant  here. 


b.  The  Steering  Function  and  Smooth  Path  Planning 
While  line  and  circle  segments  can  be  used  to  represent  a  desired  path, 
representation  of  the  path  is  only  half  the  problem.  The  second  problem  is  actually  steering 
a  vehicle  (real  or  simulated)  towards  and  along  the  desired  path.  This  is  the  role  of  tl 
steering  function.  The  steering  function  is  a  continuous  function  based  on  the  vehich 
current  state  and  the  desired  path  [Kanayaina  ‘)6].  Vehicle  state  includes  a  tran.sfotmalic'n 
to  represent  vehicle  position  and  orientation  and  a  fourth  term  to  represent  the  curvature  of 
the  vehicle’s  path.  The  steering  function  is  used  to  adju.st  the  derivative  of  this  fourth  term 
to  move  the  vehicle  tow'ards  and  along  the  desired  jtatli.  The  .steering  futietion  is  given  by 
fKanuy.'ma  ^16] 


dK 

d's 


-{(•U,K  K,,)  [  //(t)  ((_,)  + rAii) 


(Eq. 46) 


where  s  and  h  tire  the  vehicle’s  ctirrent  path  curvature  and  oricnltinon,  k,,  and  t),y  are  the 
vehicle’s  desired  path  curvature  and  orientattoii.  tui  is  the  signed  di.statice  of  the  vehicle 
fioni  the  desired  path  and  a  ,  h  .and  r  are  constants.  <  'i  it  i<  :illy  damped  values  for  n ,  h  and 
(  (vakic.s  that  vvdl  result  lu  at  nmsl  one  overshoot)  are  computed  as  jKanayama  96| 

a  ::  ’  (Eq.  47) 

h  \  (Eq.  48) 

C( 


<  {Eq.4y) 
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where  o  i  .la  -biliary  po  .itive  consltint  corn  spontliitg  to  the  vehicle’s  desired 
ivsp'ios:  venc.ss  i  ■  i  vulue,'.  ol  r-  will  eai!:;j' Ilje  vi  iiiele.  to  steer  more  sharply  tov/aids  the 
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the.  desired  path.  Figure  20  shows  an  illustration  of  a  path  tracking  problem.  As  can  be  seen 
in  the  illustration,  the  steering  function  must  be  able  to  not  only  maintain  the  vehicle  on  the 
desired  path  but  steer  the  vehicle  towards  the  path  if  necessary. 


Desired  Path 


Vehicle  ^ 

i'igurc  20;  Steering  Function  Terms  |Kanayama  96]. 

T* 

When  a  vehicle  detined  by  (  x ,  y ,  0 ,  k  )  is  tracking  a  line  defined  by 
(.X(, ,  v„,  6(1  )*,  K,;  is  zero,  o,,  is  6„  and  is  computed  as  [Kanayania  %] 


■  (,v  -  ,«„).siti(6o)  +  (  V  -  v’„)cos(Go) 


(Hq.  .50) 


For  the  same  vehicle  tracking  a  circle  defined  by  (  u, ,  y„  6„ ,  k,,  )  ‘ ,  k,,  is  k,,  .  O.y  and  (vi  are 
computed  .as  [Kanayama  96 1 


6,y  r-  stant.siiitO,,)  I  K|)  ■  (  .v„),  (co.stO,,)  k„  (v  v,,))! 


(F;q.51) 


(.X  •  (x  .v,|)  I  2.sin(e„))  (v  VnXKii  ■  D  Ju)  i 

•  -t  '  (•*  hi)  sin(^)))''  +  (Ko  ■  (V  -  V'o)  -  *•<«(()„))' 


(Ft].  52) 


respectively. 


Circular  Iransldrmations  are  u.scd  along  witli  (he  steeling  luiii  lion  to 


iiK  rcnienlally  steer  the  vehicle  along  (he  desired  palh.  At  each  iteration  tlie  slcci  iiig 
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function  is  used  to  compute 
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ds  ' 


The  vehicle’s  new  position  and  orientation  is  then 


computed  as 


(^As,  ~  ■  Ajfj  (Eq.  53) 

where  q  is  the  transformation  representing  the  vehicle  position  and  orientation  at  the 
beginning  of  the  iteration  and  As  is  the  circular  distance  traveled  in  each  iteration.  The 
updated  value  for  k  is  computed  as 


•  =  k  +  ^?.A.v  (Eq.54)  • 

Figure  21  shows  the  track  of  a  simulated  vehicle  steered  using  thi;'  method.  The  desired 

path  of  the  figure  consists  of  two  line  segments  and  a  circle  segment, 
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Figure  2 1 :  Tracking  to  a  Desired  Path  Using  the  Steering  Function. 
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3.  Recovery  Planning 


a.  Overview 

While  Phoenix  is  capable  of  six-DOF  motions,  recovery  path  planning  is 
conducted  in  two  dimensions  in  order  to  allow  use  of  the  methodology  described  above. 
The  use  of  only  two  dimensions  places  two  limitations  upon  recovery:  vehicle  depth  and 
pitch  control  must  be  handled  independently,  and  recovery  is  only  possible  in  a  horizontally 
level  recovery  tube.  Presently  these  limitations  arc  not  considered  significant,  however 
future  work  may  include  the  expansion  of  these  algorithms  to  take  advantage  of  Phoenix' 
six-DOF  capability  Uj  .support  recovery  in  tubes  of  arbitrary  orientation. 

The  steering  function  derived  above  is  intended  primarily  for  vehicles 
restricted  to  arbitrary  tangential  motions  [Kanayama  96].  Such  vehicles  are  typically 
incapable  of  lateral  motion  but  are  assumed  to  be  capable  of  following  a  path  of  unlimited 
curvature.  Since  the  steering  function  is  being  u.sed  only  for  motion  planning  and  not  for 
motion  control,  the  steering  function  remains  appropriate  for  recovery  path  planning  even 
though  Phoenix  is  capable  of  nontangential  motions.  In  this  implementation  a  planning 
vehicle  that  is  restricted  to  tangential  motions  is  used  to  generate  a  smooth  path.  The  initial 
position  ot  die  virtual  vehicle  is  .set  to  Phoenix'  position  at  the  .start  oi  the  recovery 
evolution  while  the  initial  orientation  of  the  virtual  vehicle  points  directly  at  the  center  of 
the  recovery  tube  (unless  Phoenix  is  too  close  to  the  tiilie  in  which  ease  it  points  tlirectly 
away  fioin  the  center).  The  steering  function  is  then  u.sed  to  drive  the  virtual  vehicle 
around  and  into  the  recovery  tube  to  generate  the  recovery  path.  During  the  actual  recovery 
Phoenix  must  attempt  to  stay  on  the  planned  path  but  is  not  limited  solely  to  tangential 
motions. 

Aiuither  issue  coneerning  the  u.se  ot  this  methodology  lor  AUV  path 
planning  is  dealing  with  unintentional  sideslip.  While  it  is  reasonable  to  a.s.sume  that  the 


v' 


velocity  vector  of  a  wheeled  vehicle  will  be  aligned  with  the  longitudinal  axis,  the  same 
cannot  be  said  for  vehicle’s  such  as  Phoenix.  Not  only  are  lateral  velocity  components 
possible,  they  are  in  large  part  unavoidable.  Figure  ?2  shows  the  geometry  involved  in  this 
type  of  holonomic  system.  In  the  figure,  v^i  repre.sents  vehicle  heading,  (i  represents  vehicle 
sideslip  angle,  and  i3  is  the  velocity  vector  orientation,  while  u  and  v  are  components  of  the 
velocity  vector  in  vehicle  coordintites. 


Figure  22:  Holonomic  System  Geometry  IMcGhee  91 1. 


I'he  lateral  component  of  Phoenix  velocity  vector  can  be  partially  controlled 
using  lateral  thrusters.  A  portion  of  the  lateral  velocity,  however  is  dependent  on  the 
Imigitiidinai  ve'ority  and  the  turn  rate.  While  rigorou.s  modeling  of  tliis  phenomenon  can 
become  extremely  cttinplex,  a  fairly  simple  model  can  be  used  to  predict  sideslip  angle. 
This  model  results  in  the  e.(|uation  [McGhee  SHj 
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wliere  m  is  the  vehicle  mass,  p  is  the  density  of  the  medium,  A  is  the  lateral  surface  area 
of  the  vehicle,  V'  is  the  magnitude  of  the  vehicle  velocity  (including  sideslip),  and  is  a 
constant  relating  to  lift  forces  generated  as  a  result  of  sideslip.  Using  this  equation,  an 
estimate  of  sideslip  angle  can  be  maintained  as  part  of  the  vehicle  state.  Computer 
simulation  indicates  that  niatlicrnatical  modeling  of  sideslip  in  this  manner  is  particularly 
u.seful  during  waypoint  navigation  [Davis  95]. 

Because  of  the  low  veiocitics  and  turn  rates  involved  during  hover  and 
recovery  operations,  the  uncommanded  sideslip  angle  is  .small  when  compared  to 
commanded  sideslip  induced  by  the  lateral  thru.sters.  Since  the  larger  tenn  dominates  the 
smaller,  it  is  safe  in  the  tube  recovery  .scenario  to  ignore  uncommanded  sideslip. 
Additionally,  errors  due  to  miscalculation  of  sideslip  of  other  six-DOF  holonomic  effects 
due  to  added  mass  and  other  cross  coupled  hydrodynamic  drag  forces  arc  not  allowed  to 
accumulate  during  execution  because  of  the  frequent  recalculation  of  the  AUV  position 
relative  to  the  recovery  tube. 

h.  Desired  Path  Planning 

For  overall  recovery  planning  purpo.scs,  the  area  surrounding  the  recovery 
tube  is  divided  into  nine  regions.  Bach  region  corresponds  to  the  Voronoi  regi'  .1  of  a 
segment  or  corner  of  the  tube  [Kanayama  96].  A  line  or  circle  representing  a  desired  path 
is  defined  for  each  region.  With  the  exception  of  the  line  repre.senting  the  final  tube  entry 
path,  the  desired  path  circles  and  lines  maintain  a  con.stant  safe  standoff  distance  of  six  feet 
from  the  tube.  Additionally,  all  lines  and  circles  are  directed  towards  the  opening  of  the 
recovery  tube.  The  transformation  representations  of  the  ilesired  path  lines  and  circles  are 
computed  as  soon  as  the  position  and  orientation  of  the  recoveiy  tube  are  known.  An 
example  olTube  regions  and  desired  (niths  is  shown  in  Figure  23. 


Figure  23:  Voioiioi-Based  Recuvery  Regions  and  Patii  Planning  Seginenls. 

The  next  step  is  determining  wliich  region  Phoenix  is  in  at  the  beginning  of 
the  recovery  evolution.  Since  the  size,  shape,  position  and  orientation  of  the  tube  are 
known,  this  is  simply  a  matter  of  computing  the  ranges  from  Phoenix  to  the  different 
segments  and  comers  of  the  tube  and  determining  which  is  closest.  After  deciding  which 
region  the  AUV  is  starting  the  recovery  from,  the  planning  vehicle  is  instantiated  and 

iiix^ietiiWii  \.fAi  t  y  1 1 /  V  VY  cil  VI  o  V I W  vj.v^ol  I  I  z  well  1  v/t  v  (v^  I  I  11^  icav'  II  i  vtiiv^i.i  vzii< 

As  the  planning  vehicle  leaves  one  region  and  enters  another,  the  desired  p:\th  for  tiie  new 
region  is  used,  'fhe  [ilaniiing  vehicle  has  left  one  region  and  enicied  another  when  the 
distance  from  the  vehicle  to  the  corner  or  segment  defining  the  cui  rent  region  is  greater  than 
the  distance  of  the  vehicle  to  the  corner  or  segment  delining  the  new  region.  This  process 
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continues  until  the  planning  vehicle  has  entered  the  tube.  The  path  that  the  planning  vehicle 
travelled  represents  the  planned  recovery  path  for  the  actual  AIJV. 

Again,  since  Phoenix  is  apable  of  nontangential  motion,  neither  0^  in  the 
steering  function  nor  0  of  the  planning  vehicle  necessarily  coirespond  to  the  desired 
orientation  of  Phoenix  during  the  recovery.  In  fact,  in  order  to  facilitate  continuous  sonar 
contact,  Phoenix  will  normally  point  directly  at  the  portion  of  the  recovery  tube  upon  which 
it  is  taking  station.  This  vehicle  orientation  policy  has  an  exception  in  the  final  recovery 
phase  when  the  AUV  will  be  aligned  with  the  recovery  tube  (although  and  0  still  bear 
no  correlation  to  desired  AUV  orientation).  Thus  0  and  0^  pertain  to  the  tangential 
orientation  of  the  track  the  AUV  is  to  follow,  while  actual  vehicle  heading  is  determined 
by  the  relative  bearing  to  the  sonar  tracking  landmark.  Precise  six-  DOF  maneuverability 
and  control  of  posture  using  the  nontangential  motion  capabilities  of  Phoenix  permit  such 
a  decoupling  between  vehicle  track  and  vehicle  orientation. 

C.  EXECUTION  COMMAND  GENERATION 

Which  comer  to  use  for  generated  station-keeping  commands  depends  on  the 
recovery  region  that  the  planning  vehicle  is  in  when  the  command  is  generated.  The  comer 
must  be  visible  from  anywhere  within  the  region  and  the  AUV  sonar  routines  must  be  able 
to  recognize  the  edge.  Since  the  target-search  and  edge-tracking  sonar  modes  use  range 
information  to  recognize  targets,  there  must  be  a  significant  increase  in  range  as  the  sonar 
scans  past  the  comer.  Figure  24  shows  which  comers  are  used  for  station-keeping 
command  generation  for  the  different  regions. 
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Figure  24:  Recovery  Regions  and  Station-Keeping  Comer  Assignments. 

.  .t  predetermined  intervals  along  the  planning  vehicle’s  path,  execution-level 


commands  are  generated  and  stored  in  a  file.  Generated  commands  invoice  the  execution 
level’s  edge-tracking  .sonar  mode  and  station-keeping  control  mode.  Commanded  stations 
in  each  Voronoi  region  are  in  the  form  of  range  and  bearing  from  the  planning  vehicle’s 
current  location  to  the  appropriate  tube  comer  that  Phoenix’  ST  1 CKX)  sonar  is  most  likely  to 
be  able  to  discriminate.  Interestingly,  it  must  be  noted  that  comnands  ioi  the  entire 
recovery  are  generated  before  any  command  is  issued  to  the  execution  level.  Upon 
completion  of  the  recovery  through  the  appropriate  Voronoi  regions  plan  the  OOD  module 
will  dequeue  and  issue  the  generated  commands  one  at  a  time. 

The  final  command  that  is  generated  is  the  recovery  command.  Vr^hen  issued  to  the 
execution  level,  tins  command  will  invoke  Phoenix  recovery  control  mode.  The  recovery 


command  will  be  generated  immediately  after  the  planning  vehicle  has  entered  the 
recovery  tube  opening. 

An  example  of  recovery  planning  and  virtual  world  results  are  shown  in  Figures  25 
and  26.  Figure  25  shows  the  execution-level  commands  generated  for  use  during  the 
recovery  while  Figure  26  shows  an  x-y  plot  of  the  recovery  tube,  the  planned  path,  and  the 
actual  path  followed  by  Phoenix  in  a  virtual  world  test.  The  running  of  this  and  other  test 
missions  is  discussed  in  Chapter  VII. 


#RECOVERY  REGION  7 

EDGE-STATION  6.231679  109.801091  6.231679  104.801091 
EDGE-STATION  8.541297  1 15.850068 
EDGE-STATION  9.411731  133.894357 

#RECOVERY  REGION  8 

EDGE-STATION  1 1 .636344  70.63 1 1 82  11 .636344  75.63 1 1 82 
EDGE-STATION  7.209702  101.2661 15 
EDGE-STATION  5.999095  134.868091 

#RECOVERY  REGION  9 

EDGE-STATION  9.332900  148.086638  9.332900  153.086638 
EDGE-STATION  8.587834  171.619319 
EDGE-STATION  7.367044  -168.706232  -135.000000 

#RECOVERY  REGION  1 

EDGE-STATION  4.239524  -166.878360-135.000000 
EDGE-STATION  4.239524  -166.878360  135.000000 
EDGE-STATION  3.240133  -174.693612  -135.000000 

#FINAL  TUBE  ENTRY 
ENTER-TUBE  7,499992  -135.000000 


Figure  25:  Generated  Commands  Based  on  a  Recovery  Plan. 
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East  ->  (y_world)  [ft] 
Sat  Jun  15  16:57:37  1996 


Figure  26;  Planned  and  Actual  Recovery  Path  Results  from  a  UVW  Mission. 

D.  SUMMARY 

Implementation  of  features  at  the  tactical  level  in  support  of  recovery  ii.cludc 
recovery  path  planning  and  command  generation.  Recovery  path  planning  utilizes  a 
mathematical  structure  called  a  transfonnation  which  is  used  to  represent  vehicle  position 
and  orientation  and  discrete  motions  in  two  dimensions.  The  planned  recovery  path  is 
generated  by  a  planning  vehicle  which  is  driven  by  a  steering  function  from  Phoenix 
position  at  the  start  of  the  tube  recovery  evolution. 

The  area  suire  iiidiiig  the  recovery  tube  is  divided  into  nine  VoroiiOi  regions,  eacli 
of  which  has  an  associated  desired  path.  As  the  planning  vehicle  passes  through  each 
region,  the  steering  function  drives  the  vehicle  towards  the  desired  path  for  that  region.  A 
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corresponding  tube  comer  is  chosen  for  optimal  sonar  discrimination  while  tracking.  The 
path  traveled  by  the  planning  vehicle  becomes  the  planned  path  for  Phoenix  during  the 
actual  recovery  maneuver. 

At  predetermined  intervals  along  the  planning  vehicle’s  path,  execution-level 
commands  are  generated  and  stored  in  a  file.  These  commands  are  later  iisued  to  the 
execution-level  one  at  a  time  by  the  OOD  module.  The  commands  use  the  execution 
level’s  station-keeping  behavior  to  follow  the  planned  path.  When  the  planning  vehicle  has 
entered  the  recovery  tube’s  opening,  path  planning  is  complete.  A  recovery  command  is 
then  generated  that  will  invoke  the  execution  level’s  recovery  control  mode  for  actual  entry 
into  the  recovery  tube. 

The  following  chapter  discusses  strategic  level  issues  dealt  with  in  the  conduct  of 
this  research.  Research  at  this  level  focuses  primarily  on  mission  specification,  planning 
and  generation.  Specific  issues  include  evolution  of  the  strategic  level  and  the  development 
of  a  mission  planning  expert  system. 
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VI.  STRATEGIC  LEVEL  IMPLEMENTATION 


A.  INTRODUCTION 

Since  the  strategic  level  of  Ri8M  is  responsible  only  for  high-level  mission  control, 
its  responsibilities  regarding  recovery  are  few.  Essentially,  the  strategic  level  is  respoissible 
only  for  deciding  where  and  when  the  recovery  is  to  take  place,  and  what  type  of  recovery 
is  required.  This  role  is  analogous  to  that  of  a  ship’s  commanding  officer  who  specifies 
what  port  to  go  to,  v.'hen  to  go  there,  and  whether  to  anchor  or  dock,  but  is  not  physically 
involved  in  the  actual  anchoring  or  docking  evolution. 

Because  of  the  limited  role  of  the  strategic  level  in  recovery,  research  conducted  at 
this  RBM  level  has  been  more  general  in  nature.  The  most  significant  result  has  been  to 
simplify  the  process  of  strategic  level  mission  planning  and  generation.  The  following 
section  of  this  chapter  describes  implementation  of  features  at  the  strategic  level  that 
facilitate  this  goal.  The  subsequent  section  describes  the  implementation  of  a  graphical 
expert  system  for  mission  planning  am  automatic  strategic-level  code  generation. 

B.  EVOLUTION  OF  THE  STRATEGIC  LEVEL 

1.  Mission  Control 

As  stated  previously  the  strategic  level  i.s  structured  as  a  DFA  and  consists  of  three 
software  pieces;  the  DFA,  the  mission  controller  and  a  set  of  primitive  goals.  The  mission 
controller  is  shown  in  Figure  27  implemented  equivalently  in  Prolog  and  C-I-+.  Looping  in 
the  Prolog  implementation  is  conducted  using  the  basic  Prolog  backtracking  control 
algorithm  which  tries  to  “prove”  predicates  [Rov/e  88].  When  a  mission  is  initiated,  Prolog 
tries  io  iind  a  way  to  make  the  cxecute_phase  predicate  “true”  'ny  proving  the 
executc_phase  and  mission  done  predicates.  If  the  execute_phasc  predicate  i.s  false,  the 
pha.se  has  not  yet  completed.  In  this  situation  Prolog  will  backtrack  into  the  repeat 


predicate  (which  is  always  considered  true).  It  then  retries  the  execute_phase  predicate. 
This  looping  pattern  will  continue  until  the  execute_phase  predicate  becomes  trae,  at  which 
point  the  same  process  is  executed  for  the  mission_done  predicate.  When  the 
mission_done  predicate  is  proven,  exf.cute_.mi.ssion  is  proven,  and  the  mission  completes. 
Otherwi.se,  Prolog  tries  to  prove  die  next_pha.se  predicate.  Which  version  of  this  predicate 
can  be  proven  is  determined  by  succe.ss  or  failure  of  the  current  phase.  In  contrast  to  the 
Prolog  mission  controller,  the  C++  mission  controller  uses  a  typical  imperative 
programming  language  loop  to  obtain  behavior  equivalent  to  that  of  the  Prolog  version. 

t 


execute.jfli.ss  ion 

:  -  a.sserta  { cur  rent_phase  (  initialize)  )  , 

repeat,  execute_phase,  mission_done . 

execute  phase 

current jphase (X)  ,  execute_phase (X) , 

next_pl)ias6  (X)  ,  !. 

mission_done 

current_phase (mi ssion_abort )  . 

mission_done 

current_phase  (inission_complete )  . 

(a) 

currentPhase  =  initialize  ( ) ; 
do  { 

if  (c;urrentPhase->complete  ()) 


currentPhase  =  currentPhase ->completeSuccessor ; 
currentPhase->initiate  ( ) ; 

} 

else  if  ( cun entPhase- >abor t ( ) ) 

{ 

cui rentPhase  =  currentPhase- >abortSuccessor ; 
currcntPhaGe->initiate  ( ) ; 

) 

}  while  ((currentPhase  !=  missionAbort )  && 

(currentPhase  !=  ivi.s.sionComplete)  )  ; 

(b) 

Figure  27:  Strategic  L.cv'el  Mission  Controller  in  (a)  Pn.  ;g  and  (b)  C++. 
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2.  Abstract  Mission  Control 


Since  initial  Phoenix  research  was  focused  primarily  on  the  strategic  and  execution 
levels  of  RBM,  early  versions  of  the  tactical  level  were  greatly  simplified  and  mainly 
responsible  for  simply  relaying  commands  from  the  strategic  level  to  the  execution  level 
[Marco  96b  j.  Consequently  many  tasks  appropriate  for  the  tactical  level  were  first 
implemented  at  the  execution  and  strategic  levels.  Recent  improvement  in  the  tactical 
level  now  handle  tnany  of  the  tasks  previously  divided  between  the  strategic  and  execution 
levels  [Leonhardt  96,  Campbell  96,  McClarin  96,  Scrivener  96].  This  redistribution  of 
responsibility  among  the  levels  of  Phoenix  RBM  implementation  has  allowed  strategic- 
level  functionality  to  concentrate  solely  on  the  high-level  mission  control  for  which  it  was 
originally  intended. 

With  the  reassignment  of  many  tasks  to  the  tactical  level,  it  became  apparent  that 
further  strategic-level  simplification  was  possible  by  limiting  the  allowable  phase  types  to 
a  few  generic  types.  In  fact  this  limitation  was  necessary  since  the  tactical  level  is  only 
capable  of  interpreting  strategic-level  commands  from  a  predetermined  set  of  primitive 
goals  [Marco  96b,  Leonhardt  96].  As  the  AUV’s  functionality  evolves,  nevt'  commands  can 
be  implemented  in  tandem  at  the  strategic  and  tactical  levels  by  adding  to  the  vehicle’s 
primitive  goal  set.  Pre.sent  strategic-level  primitive  goals  include  transits,  searches,  global 
positioning  system  (GPS)  fixes,  dives  and  hovers.  Because  of  the  explicit  definition  of  all 
possible  .strategic-level  primitive  goals  and  the  implementation  of  arobust  tactical  level,  the 
RBM  implementation  of  Phoenix  is  now  versatile  and  simple  enough,  to  correctly  perform 
a  wide  array  of  missions  [Brutzman  96], 

As  stated  in  Chapter  II,  the  strategic  level  does  not  peifonn  any  numerical 
computation  [Byrnes  96],  but  the  exclusive  maintenance  of  numerical  data  at  tl  .e  lower 
RBM  layers  proved  impractical  in  implementation.  This  was  due  to  the  high  likelihood  of 
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mismatches  between  the  strategic  level  DFA  and  the  numerical  data  file  used  by  the  tactical 
level  [Leonhardt  96].  The  solution  was  to  include  numbers  upon  which  a  phase  is 
dependent  (such  as  the  location  of  a  search)  in  the  command  sent  to  the  tactical  level.  The 
tactical  l“vel  interprets  the  parameters  as  numerical  values,  but  at  the  strategic  level  they 
are  just  place  boldcrs  within  tl.e  command.  The  implementation  of  phase  parameters 
eliminates  liie  possibilitv  ot  data  file/DFA  mi.smatch  errors  while  maintaining  the  overall 
non-numerical  nature  of  the  struicgic  level.  Figure  28  shows  a  strategic-level  search  phase 
with  phase  parameters  defined  in  Prolog.  Tactical -level  replies  to  strategic-level 
command'’  are  not  tested  so  a  sequence  of  strategic-level  commands  can  initiate  paiallel 
tasks  at  the  tactical  level.  Replies  to  st‘'  xtegic-lcvcl  queries  on  the  other  hand,  are  tested  so 
that  execution  does  uot  proceed  to  tJic  ne.xt  q  .ery'  or  command  until  an  appropriate  reply  to 
the  current  query  is  receiv  ed.  As  with  the  Prolog  version  of  the  mi.ssion  controller, 
backtr  eking  is  used  to  implement  looping  behavior  so  that  a  phase  will  continue  to  execute 
until  the  execute_pliase  predicate  is  uuc.  Tlic  phase  depicted  corresponds  to  the  search 
phase  of  the  mission  depicted  in  Figure  1 1 . 


# 


•  • 


e.xGoute_pha.se  (rearoh_  1) 


pha.Te^coropleLcd '  se&.roh^,3, ) 


phaiie._.complGted  ( sesx-cix_l ) 


noxL_phase ( search  1 ) 


next:_phase  ( ssart.h  _1 ) 


ood  (  ".sonai-_seai:cli  20  45  3",  Reply), 
ood  (  "start;._tiir.er  250"  ,  Kopiy)  , 
repeat.,  pl.ase_rompleted  ( oearch_l )  . 
ood(  '‘.'isle  .search_con\plete"  ,  Reply)  , 

Reply  -I,  a.r:;;erta(succeed(8oarch  1)  )  . 
ood  (  "ayk__t  i  me_uul."  ,  Reply)  ,  Kepiy=  =  l, 
a  ( abort  ( searcb_l )  )  . 
coccee;!  ( Baarcli_l)  , 

retract,  (cun flit  phase(SBarch_l)  )  , 

lEsert,?.  (current^piliase  (raturn„to_baBa)  )  . 
ckil-O  I  t  (8aarr:h_l)  , 

retract (current  phase (8#arch_i! ) , 
r,s ser  L.a  ( c'Ui  j- out _ £iliatiO(yO _ aualXOw)  }  . 


Figure  28:  Strategic  Level  Pha.se  Specihed  in  Prolog. 
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While  the  primary  goal  of  recent  strategic-level  research  efforts  has  been  the 
effective  implementation  of  RBM  in  the  real  world  [Bmtzman  96],  a  collateral  result  has 
been  the  standardization  of  the  strategic  level.  The  strategic  level  code  now  has  a  standard 
form  for  a  given  type  of  phase.  The  only  difference  between  two  distinct  phases  of  the  same 
type  is  the  parameters.  A  template  can  therefore  be  created  for  each  type  of  phase. 
Strategic  level  code  for  a  phase  can  be  easily  generated  by  inserting  a  label  and  phase 
parameters  into  a  copy  of  the  appropriate  phase  template.  The  boldface  portions  of  the  code 
fragment  of  Figure  28  indicate  the  phase  label  and  parameters  inserted  into  a  sonar-search 
template.  Using  templates  to  code  the  strategic  level  has  a  number  of  advantages.  For 
instance,  the  potential  for  syntactic  programming  errors  is  great  when  manually 
programming  even  a  simple  mission.  Such  errors  can  be  virtually  eliminated  by  utilizing 
templates.  Furthermore  pha.se  templates  make  it  possible  to  automate  strategic  level  code 
generation  and  eliminate  manual  programming  at  the  strategic  level  altogether 
[I  eonhardt  96,  Brutzman  96]. 

3.  Programming  Language  Issues 

A  decision  was  made  early  in  the  development  of  mission-control  software  for  the 
Phoenix  AUV  to  implement  the  strategic  level  using  the  Prolog  programming  language. 
Because  of  its  roots  in  predicate  calculus,  one  advantage  of  Prolog  is  that  it  is  relatively 
easy  to  use  for  specifying  mission  logic  when  compared  to  more  common  imperative 
languages.  As  a  result,  programs  written  in  Prolog  are  typically  shorter  than  equivalent 
programs  written  in  functional  or  imperative  languages.  Additionally,  programming  of  the 
strategic  level  of  the  RBM  is  primarily  a  symbolic  programming  problem  which  is  well 
suited  to  expression  in  Prolog  [Byrnes  96],  Finally,  use  of  the  Prolog  inference  engine  is 
powerful  since  the  current  state  of  the  DFA  can  be  repre.sented  implicitly  by  the  current  rule 
that  is  being  resolved  [Byrnes  96].  However,  in  the  current  .strategic  level  implementation. 
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the  DFA  state  is  maintained  explicitiy  (usii.g  dynamically  asserted  facts)  rather  than 
implicitly  in  order  to  improve  code  readability  and  ease  of  use.  This  approach  amounts  to 
specializing  the  Prolog  inference  engine  to  a  mission  control  engine  or  “mission  controller” 
[Marco  96b] , 

A  disadvantage  of  using  Prolog  at  the  strategic  level  is  that  it  must  interlace  with 
the  tactical  level  which  is  currently  written  in  C.  At  present  there  is  no  standard  Prolog 
foreign  language  interface,  so  communication  between  the  strategic  and  tactical  levels  is 
dependent  on  the  vendor  and  version  of  the  Prolog  compiler  used  [Quintus  Corporation  95]. 
Portability  of  the  software  system  to  new  platforms  is  therefore  a  problem.  Another 
disadvantage  as  missions  become  more  complex  is  that  the  size  of  the  Prolog  program 
grows  rapidly  since  each  phase  is  programmed  independently  of  all  other  phases.  Finally, 
because  of  its  reliance  on  backtracking  for  control  of  execution,  Prolog  tends  to  run  more 
slowly  than  imperative  languages  [Rowe  88].  To  date  this  has  not  been  a  problem  since  the 
speed  at  which  the  whole  RBM  system  runs  has  been  limited  not  by  the  speed  of  the 
strategic  and  tactical  levels,  but  rather  by  the  speed  of  the  execution  level  [Leonhardt  96, 
Bums  96], 

The  advantages  of  using  Prolog  for  Phoenix  currently  outweigh  the  disadvantages, 
particularly  given  the  mission  planning  expert  system  described  in  the  following  section. 
However  other  programming  languages  have  advantages  which  may  make  them  attractive 
for  use  in  the  future.  Two  strategic  levels  equivalent  to  the  one  described  above  have  been 
implemented  using  the  Lisp  and  CL  IPS  programming  languages  [Byrnes  96].  However 
these  implementa'ions  have  proved  to  be  much  harder  to  v/ritc  and  understand. 

More  recently,  research  has  been  conducted  into  implementation  of  the  RBM 
strategic  level  in  C++  using  object-oriented  programming  techniques.  The  polymorphism 
and  inheritance  characteristics  of  C++  classes  allow  the  definition  of  a  generic  phase  class 
from  which  more  specific  phase  classes  repre.senting  all  allowable  types  of  phases  can 
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inherit.  All  phase  class  definitions  together  determine  the  vehicle’s  operational 
capabilities.  A  specific  mission  can  be  generated  by  instantiating  instances  of  the 
appropriate  phase  classes  and  using  pointers  to  connect  them  into  a  graph  representing  the 
strategic  level  DFA.  As  shown  in  Figure  27  this  mission  controller  portion  of  the  strategic 
level  is  implemented  using  a  loop  that  queries  the  tactical  level  about  the  status  of  the 
current  phase.  If  the  current  phase  has  either  completed  or  aborted,  the  appropriate 
transition  is  executed  by  following  a  pointer  and  initiating  the  next  phase.  If  the  current 
phase  has  neither  completed  nor  aborted,  the  loop  repeats  v/ithout  initiating  a  new  phase. 
Implementation  of  the  strategic  level  in  C++  directly  addresses  all  three  of  the  previously 
mentioned  disadvantages  of  the  Prolog  strategic  level  (foreign  language  interface,  size  and 
speed).  Since  C++  can  be  directly  linked  with  C  functions,  the  system  is  inherently  more 
portable  than  the  Prolog  version.  Additionally,  with  the  exception  of  individual  phase 
instantiation  and  DFA  constniction,  all  code  is  contained  within  the  phase  class  definitions. 
Therefore,  as  mission  complexity  increases,  the  size  of  a  strategic  level  source  program 
does  not  increase  as  rapidly  as  an  equivalent  mission  written  using  Prolog.  In  the  current 
C++  implementation,  the  size  of  the  source  program  will  typically  increase  by  two  lines  for 
each  additional  phase  (one  line  to  instantiate  the  phase  object,  one  line  to  link  the  object 
into  the  DFA  graph).  On  the  other  hand,  the  very  conciseness  of  this  approach  tends  to 
present  a  barrier  to  easy  understanding  of  the  meaning  and  behavior  of  the  vehicle  in 
executing  a  mission  so  encoded.  Thi.s  difficulty  is  resolved  by  the  development  of  a 
mission-generation  expert  system  as  explained  in  the  following  section. 

c.  A  mission-(;enp:katk)N  expert  systeivi 

1.  Introduction 

In  mo.st  scenarios  involving  the  use  of  Phoenix  eVdas  AlJVs  for  mine 
countermeasure  missions,  operational  naval  personnel  would  be  responsible  for  generation 
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of  mission  control  software.  While  these  individuals  can  be  expected  to  be  experts  in  anti- 
ine  warfare,  they  are  unlikely  to  have  a  high  skill  level  in  computer  programming. 
Instead,  they  will  probably  require  an  easy-to-use  mission  programming  interface  in  order 
to  effectively  and  reliably  specify  an  AUV  mission.  In  this  regard  such  individuals  are 
probably  typical  ol  end  users  of  autonomous  vehicles  in  general.  [Prutzman  96] 

In  order  to  facilitate  ease  of  use,  an  expert  system  for  programming  Phoenix  AUV 
missions  has  been  developed.  This  expert  system  consists  of  three  distinct  subsystems  and 
a  graphical  user  interface  (GUI).  The  first  subsystem  is  used  to  automatically  generate 
missions  by  specification  of  overall  mission  goals.  The  second  subsystem  is  a  mission- 
specification  facility  that  can  generate  arbitrarily  complex  missions  phase-by-phase.  The 
last  subsystem  is  an  automatic  strategic  level  code  genei  ator  that  creates  Prolog  or  C+-i- 
programs  using  results  from  either  of  the  other  two  subsystems.  The  GUI,  automatic 
mission-generation  facility,  and  mission-specification  facility  have  been  implemented 
using  Quintus  Prolog  version  3.2  [Quintus  Corporation  95]  and  XPCE  version  4  for  X- 
windov.'s  (Prowindows)  [Wielemaker  94).  The  strategic  level  code  generator  is  written 
using  C  and  can  either  be  invoked  explicitly  as  a  standalone  application  or  automatically 
from  within  the  expert  system  itself. 

2.  The  Automatic  Mission  Generator 

a.  Means-Ends  Analysis 

The  intent  of  the  automatic  mission  generator  is  to  allow  the  user  to  generate 
a  mission  simply  by  specifying  the  AUV  launch  position,  recovery  position  and  mission 
objectives.  A  means-ends  analysis  algorithm  is  used  to  implement  the  automatic  mission 
generator.  In  general,  means-ends  analysis  uses  a  set  of  start  conditions,  a  set  of  desired 
end  conditions,  and  a  set  of  operators  to  derive  a  sequence  of  operations  that  will  eventually 
transform  the  system  from  tlie  start  state  to  the  desired  end  state  [Rowe  88,  Winston  92]. 
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In  the  automatic  mission  ”,enerator  implementation  of  means-ends  analysis,  start  conditions 
are  the  vehicle  launch  position,  end  conditions  are  the  mission  objectives  and  vehicle 
recovery  position,  and  the  operators  represent  all  possible  phase  types.  The  automatic 
mission  generatoi  applies  the  means-ends  analysis  algorithm  to  produce  results  similar  to 
those  of  Figure  29  which  depicts  a  search  mission. 


Figure  29:  Search  Mission  Automatically  Generated  with  Means-Ends  Analysis. 

In  means-ends  analysis,  two  mechanisms  insure  that  a  valid  .sequence  of 
operations  is  generated.  First,  each  condition  in  the  desired  end  state  has  one  or  more 
recommended  operators,  for  example  if  the  desired  end  state  is  that  a  location  has  been 
searched,  the  recommended  operator  is  to  conduct  a  sonar  search  from  the  required 
location.  Second,  each  operator  has  a  .set  of  required  preconditions  that  must  be  satisfied 
before  the  operator  can  be  applied  as  well  as  a  set  of  postconditions  that  re.sult  from  the 
application  of  the  operator  [Rowe  88 1.  Th  'reconditions  for  thr  sonar  search  of  position 
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P,  for  instance,  might  be  that  the  vehicle  is  near  position  P  and  that  the  position  must  be 
verified  by  a  GPS  fix.  An  obvious  postcondition  of  a  sonar  search  is  that  position  P  has 
been  searched.  The  means-ends  algorithm  uses  these  two  mechanisms  by  choosing  one  of 
the  desired  end-state  conditions  and  attempting  to  apply  a  recommended  operator.  If  the 
preconditions  of  the  recommended  operator  have  not  been  satisfied,  the  algorithm  attempts 
to  satisfy  the  preconditions  by  recursively  applying  means-ends  analysis.  If  the 
preconditions  are  satisfied  in  this  way,  the  operator  is  applied.  If  the  preconditions  cannot 
be  satisfied,  the  next  recommended  operator  is  attempted.  The  algorithm  proceeds  in  this 
manner  until  all  of  the  top  level  goals  have  been  satisfied  or  until  all  recommended 
operators  have  been  exhausted.  If  the  operators,  precond  '  ions  and  postconditions  are 
correct,  means-ends  analysis  is  guaranteed  to  compute  a  valid  sequence  of  operations  for 
accomplishing  the  desired  goals  [Rowe  88].  Since  means-ends  analysis  is  used  to  generate 
a  sequence  of  phases,  any  sequence  of  phases  generated  can  be  logically  executed  by  the 
Phoenix  AUV  and  will  accomplish  all  of  the  goals  specified. 

b.  Adaptation  of  Means-Ends  Analysis  for  Phoenix 

The  means-ends  analysis  implementation  of  the  mission-planning  system 
divides  goals  into  two  types.  Top-level  goals  are  those  that  are  specified  by  the  user  while 
intermediate  goals  are  used  during  recursive  applications  of  the  means  ends  analysis  to 
accomplish  top  level  goals.  Intermediate-level  goals  appear  as  preconditions  and 
postconditions  of  top-level  goals  and  other  intermediate-level  goals.  At  present  the  top 
level  goals  implemented  for  Phoenix  are  position  searches,  position  searches  with  specific 
routing,  and  entry  into  a  recovery  tube.  As  the  functionality  of  lower  layers  of  Phoenix 
software  architecture  evolves,  high  level  goals  will  be  implemented  to  take  advantage  of 
new  capabilities.  Future  high  level  goals  may  include  planting  explosive  charges, 
communicating  with  the  controlling  platform  and  taking  still  photographs. 
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There  are  a  number  of  characteristics  of  the  solutions  obtained  using  means- 
ends  analysis  as  presented  in  [Rowe  88]  and  [Winston  92]  that  are  not  well  suited  to 
planning  for  autonomous  vehicles.  The  first  is  that  solutions  obtained  through  means-ends 
analysis  are  linear  in  nature.  A  basic  assumption  of  the  algorithm  is  that  operations  always 
succeed  so  there  is  no  attempt  to  account  for  phase  failure.  This  means  that  when  the 
mission  DFA  is  constructed,  another  algorithm  or  heuristic  must  be  used  for  failure 
handling.  The  simplest  and  most  obvious  solution  is  to  make  the  arbitrary  decision  that  if 
a  phase  fails,  the  mission  aborts.  However,  if  this  simple  heuristic  is  used,  the  resulting 
DFA  amounts  to  no  more  than  a  simple  script  that  goes  from  one  operation  to  the  next  and 
stops  whenever  an  operation  fails.  Similar  solutions  such  as  having  the  vehicle  proceed  to 
its  launch  point  or  recovery  point  share  this  failing.  Another  possible  solution  might  be 
reattempt  any  failed  phase.  The  obvious  disadvantage  here  i.s  that  if  a  phase  cannot  be 
successfully  completed,  the  mission  may  not  end  until  the  vehicle  exhausts  its  power 
supply.  The  solution  that  was  opted  for  is  to  always  attempt  to  proceed  forward  with  the 
mission  in  the  event  of  individual  phase  failure.  If  any  phase  fails,  the  .succeeding  phase 
will  be  the  next  transit  or  hover  phase  to  be  executed  had  the  phase  succeeded  (the 
exception  is  the  initial  dive  to  operating  depth).  In  this  way  if  one  or  more  phases  fail,  the 
vehicle  will  still  attempt  to  accomplish  as  much  of  the  mission  as  possible.  Transit  and 
hover  phases  were  chosen  as  the  phase  failure  successor  type  because,  unlike  other  types 
of  phases  (.such  as  searches  and  GPS  fixes),  transit  and  hover  phases  never  directly  rely  on 
their  predecessor  phase.  A  graphical  representation  of  the  DFA  resulting  from  the  means- 
ends  analysis  solution  of  Figure  29  is  shown  in  Figure  30. 
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The  second  disadvantage  of  means-ends  analysis  is  that  operators  are 
implicitly  prioritized  by  their  order  of  appearance  in  the  means-ends  analysis  specification. 
For  instance  if  the  operators  search  position  P  and  plant  an  explosive  charge  at  position  P 
are  specified  in  that  order,  the  solutions  obtained  by  means-ends  analysis  will  always  apply 
the  search  position  P  operator  as  many  times  as  it  can  before  it  attempts  to  appiy  the  plant 
an  explosive  charge  at  position  P  operator.  If  mission  goals  included  a  search  of  position 
(X],  yj,  Z]),  an  explosive  charge  plant  at  position  (X|,  y  |,  Zj),  a  search  of  position 
(X2,  y2.  Z2)’  explosive  charge  plant  at  position  (X2,  y2,  2.2),  the  means-ends  analysis 

solution  will  conduct  both  searches,  then  plant  both  explosive  charges.  While  this  may  be 
the  type  of  behavior  desired,  if  the  transits  between  (Xj,  yi,  zj)  and  (X2,  y2>  ^2)  cover  a 
ignificant  distance,  missions  of  this  sort  become  highly  inefficient.  The  problem  of 
operator  prioritization  is  only  a  problem  for  operators  intended  fo  accomplish  top-level 
goals  since  the  ordering  of  intermediate-level  goals  do  not  significantly  effect  a  mission’s 
efficiency.  The  .solution  tc  this  problem  is  the  implementation  of  a  single  operator  that 
accomplishes  all  top-level  goals.  What  type  of  top  level  goal  to  accomplish  is  specified  by 
the  parameters  of  the  operator.  Different  sets  of  preconditions  and  postconditions  are  then 
defined  for  each  form  of  the  single  operator.  Since  only  a  single  operator  is  involved, 
prioritization  is  no  longer  an  issue.  Figure  31  shows  this  operator  definition  for  the 
accomplishment  of  searches  and  explosive  placements  (to  date,  the  .search  operator  has 
been  fully  implemented  in  the  vehicle,  but  not  the  explosive  placement  operator). 


95 


O 


%Recommended  operators  for  goals .  Format  is 
%goal,  operator 

recommended (top_level„done (X) ,  handle_top„level (X) ) . 


%Preconditions  for  the  application  of  operators 
%Format  is  type  of  operator,  precondii  Lons  that 
%must  be  true  list,  and  preconditions  that 
%must  not  be  true  list 

precondition (handle_top_level  (  [searched,  X,  Y,  /, ]  )  , 
[position(X,Y,Z) ] , 

[explosive_ready, gps_f ix_reguired] ) . 
precondition (handle_top_level ( [charged, X, Y , Z] ) , 

[position  (X,  Y,  Z!  ,  exi;l.osive_ready]  , 

[gps._f  ix_required]  )  . 

%Postcondition3  for  the  application  of  oi^erators 
%Add  postconditions  are  true  after  application 
%Delete  postconditions  are  false  after  application 

addpostcondition(handle„top_.level ( [searched, X,Y, Z) ) , 

[  top_level_d''ne  (  [ searched,  X,  Y,  Z]  )  , 
gpis  _f  ix_required]  )  . 

deletepostcondition(handle_top_,level ( [searched, X, Y, Z) ),[]). 
addpostcondition (handle_rop_level ( [charged, X,Y, Z] ) , 

[ top_ level _done ( [searched, X, Y, Z) ) ) ) . 
de.l etepostcondition  (handlG_top_,lGvel  (  [charged,  X,Y,  Z]  )  , 
[explosive_ready] ) . 


Figure  3 1 :  Top-Level  Operator  Definitions  for  Search  and  Explosive  Planting  Goals. 

One  final  potential  shortcoming  of  means-ends  analysis  is  that  while  the 
initial  solution  obtained  is  guaranteed  to  be  valid  and  complete,  more  optimal  .solutions 
may  exist  that  can  only  be  produced  through  repeated  applications  of  the  means-ends 
analysis  algoritlim.  A  possible  solution  to  this  .shortcoming  might  be  to  obtain  all  solutions 
possible  using  means-ends  analysis,  compare  them  for  efficiency,  and  use  the  most 
efficient  one  as  the  final  solution.  Another  solution  is  to  again  obtain  all  possible  solutions 
but  allow  the  user  to  choose  the  one  to  be  used.  A  slight  modification  of  the  second  solution 
is  cunently  used  in  the  system.  After  a  user  .specifies  the  vehicle’s  launch  position,  mission 


goals  atid  recovery  position,  the  means-ends  analysis  algorithm  is  applied  to  obtain  a 
solution.  The  solution  is  displayed  textually  in  a  window  similar  to  the  one  in  Figure  29 
and  a  geographic  plot  of  the  mission  path  is  displayed  on  an  area  map.  The  user  is  then 
given  the  option  of  accepting  or  refusing  the  mission.  If  the  mission  is  refused,  the  means- 
ends  analysis  algorithm  is  applied  to  generate  another  solution.  Using  this  approach  the 
user  can  cycle  through  all  obtainable  solutions  one  at  a  time  prior  to  .selecting  one. 

3.  Phase-by-Phase  Mission  Specification 

While  means-ends  analysis  provides  a  simple  method  for  generating  fairly  complex 
missions,  it  is  incapable  of  generating  missions  that  take  full  advantage  of  the  DFA 
structure  of  the  strategic  level.  Therefore  a  facility  has  been  developed  for  explicit 
.specification  of  individual  phases  that  can  be  linked  together  more  or  less  arbitrarily  into 
an  executable  mission.  The  mission-specification  facility  queries  the  user  for  information 
for  each  phase  and  uses  information  for  all  input  phases  to  construct  a  mission.  Information 
for  each  phase  includes  a  phase  label,  the  type  of  phase,  phase  parameters,  the  label  of  the 
follow-on  phase  upon  successful  completion,  and  the  label  of  the  follow-on  pha.se  upon 
phase  failure.  The  expert  system  GUI  insures  that  the  user  enters  the  appropriate 
information  at  the  appropriate  time.  For  instance,  if  a  transit  phase  is  being  entered,  the 
system  will  not  ask  for  search  related  information.  The  GUI  also  eliminates  many  data 
entry  errors  by  the  use  of  clickable  maps,  push  buttons,  clickable  menus,  and  sliding  scales. 
Sample  GUI  data  entry  windows  are  ,;hown  in  Figures  32  and  33.  Figure  32  shows  the  main 
window  which  is  used  for  launching  system  facilities  and  visual  entry  and  display  of 
geographic  information.  Figure  33  shows  windows  for  .specifying  the  type  of  phase  to  be 
entered  and  phase  related  data  for  a  transit  pha.se.  Data  entry  windows  for  other  types  of 
pha.ses  are  similar  to  the  one  shown  in  Figure  33  but  differ  m  the  specific  data  entered. 
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Since  manual  phase-by-phase  specification  of  a  mission  can  be  much  moic 
complicated  than  specifying  a  mission  using  means-ends  analysis,  a  mie-based  system  lias 
been  implemented  to  insure  chat  only  valid  missions  a-e  generated  by  the  system.  This 
requires  checking  each  entered  phase  for  validity  in  .several  ways.  The  phase  mu.:t  not  be 
missing  any  parameters,  vehicle  physical  limitations  must  be  observed,  and  the  specified 
locations  must  be  within  the  designated  operating  area.  This  check  is  conducted  as  each 
phase  is  entered.  Detected  errors  are  immediately  reported  and  the  user  is  given  the 
opportunity  to  modify  the  phase.  .If  no  errors  are  detected,  the  phase  is  accepted.  I.,ater,  a 
second  check  is  required  to  insure  that  all  of  the  phases  together  make  a  valid  mission.  In 
general,  many  phases  are  inherently  dependent  upon  their  predecessors,  so  it  is  possible  for 
a  set  of  individually  valid  phases  to  constitute  an  invalid  mission.  For  instance,  a  location 
cannot  be  searched  until  the  vehicle  has  transited  to  the  location.  Errors  of  this  type  include 
incomplete  missions,  loops  in  the  DFA,  invalid  phase  sequences  etc.,  and  are  detected  by 
parsing  with  a  second  rule  base  immediately  prior  to  mission  code  generation.  Again 
detected  errors  are  reported,  and  the  user  is  given  the  opportunity  to  modify,  delete  or 
specify  phases.  Sample  en'or  reports  for  individual  phase  errors  and  mission  errors  are 
shown  in  Figure  34.  If  no  errors  are  detected  the  mission  is  accepted  and  executable  code 
is  generated.  By  enor  checking  both  individual  phases  and  the  mission  as  a  whole,  the 
phase-by-phase  mission-specirication  facility  can  insure  that  any  specified  mission  is  valid 
and  achievable  by  the  vehicle. 
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To  assist  in  phase-by-phase  mission  development,  a  tabular  representation  of  the 
mission  is  displayed  as  it  is  entered  (Figure  35).  The  mission  is  represented  as  a  state  table 
listing  each  phase  with  the  label  of  its  follow-on  pha,se  upon  successful  completion  and  the 
label  of  its  follow-on  phase  upon  failure.  While  it  might  be  argued  that  a  graphical 
representation  of  the  DFA  (such  as  in  Figures  1 1  and  30)  is  more  intuitive,  graph 
complexity  increases  far  more  rapidly  than  that  of  a  state  table  as  mission  size  increases. 
For  arbitrarily  complex  missions,  a  state  table  is  more  concise  and  conveys  the  same 
infonnation  as  a  graph. 


Figure  35:  State  Table  Summary  of  a  Mission  Specified  Phase-by-Phase. 


•  • 


102 


4.  Automatic  Code  Generation 


Both  the  nieans-ends  mission  generator  and  the  phase-by-phase  mission- 
specification  facility  produce  output  in  the  form  of  ,i  data  file.  This  intermediate  data  file 
is  not  an  executable  strategic  level  mission  but  rather  is  an  annotated  state  table  desc  ription 
of  a  strategic  level  mission.  Each  line  in  the  data  file  describes  exactly  one  phase  by 
specifying  (in  order)  the  phase  type,  the  phase  label,  the  label  of  the  follow-ori  phase  upon 
success,  the  label  of  the  follow-on  phase  upon  failure,  the  amount  of  time  that  the  phase  has 
to  succeed,  and  the  phase  parameters.  This  output  file  format  actually  constitutes  yet 
another  RBM  mission-specification  language.  Because  of  its  high  level  of  abstraction,  the 
mission-specification  language  is  programming-language  independent  and  (together  with 
the  previously  discussed  phase  type  templates)  enables  autontated  executable  code 
generation  in  any  language  for  which  phase  templates  have  been  created. 

To  date,  phase  type  templates  for  the  have  been  created  for  Prolog  and  C++. 
Concurrent  with  template  development  has  been  the  construction  of  programs  to  generate 
executable  code  for  missions  specified  using  the  mission-specification  language.  Figure  36 
shov/s  an  example  of  a  mission  specified  with  the  mission-specification  language  and  the 
automatically  generated  executable  code.  Code  generation  programs  are  written  using  the 
C  programming  language  and  can  be  run  as  standalone  programs  or  invoked  from  within 
the  mission  planning  expert  system.  Standalone  execution  can  be  used  to  generate  a 
mission  ba.sed  on  a  user-specified  data  file  which  can  be  automatically  or  manually  created. 
From  within  the  mission  planning  expert  system,  executable  code  is  generated  for  a  mission 
specified  phase-by-pha.se  or  by  means-ends  analysis.  While  the  tnis.sion  planning  system 
as  a  whole  is  dependent  upon  availability  of  Quintus  Prolog  and  Prowindows,  the 
programming  language  independence  of  the  mission-specification  language  allows  this 
portion  of  the  system  to  be  ported  to  virtually  any  platform. 


.4ri 


•  •  •  • 


•  •  • 


UJ3 


^Mission  Speci f iration  Pile  Format 


#phase_.i:ype 

phase_label 

completion_.successor 

abort_successor 

[parajTietei 

f] 

1 

d€pth_change 

dive 

t-.ransit_to_op_area 

mission_abort 

30 

3 

waypoint 

transi t_to_op_atea 

hovcr^.l 

go^shallow 

500 

15 

30 

3 

hovcrpoint 

hover_l 

search_l 

go_shallow 

500 

20 

45 

3 

134 

rotate_sonir.. search 

search_l 

rctum_to_base 

go^shallow 

200 

20 

45 

3 

hoverpoint 

return  _ t  o_bas  e 

surface 

mission_abort 

250 

64 

30 

2 

222 

cJepth_change 

surface 

mission_coroplete 

mission_abort 

150 

0 

depth_c?hange 

go_shallow 

retum_to^base 

mission_abort 

100 

1 

(a)  Mission-specification  Language  Exaunple 


execute _phase (hover_l ) 

nl.  printsc (’ PHASE  hover_l  STARTED.'), 

ood( 'hover  20  45  3  135 Reply ) , 

print sc ( ‘hover  20  45  3  135!'), 
ood{ ‘ starc_timer  500', Reply), 
repeat  •‘hase_.compleced(hover_l)  . 

phase_completed (hover_l) 

ood( 'ask_hoverpoinC_reachcc ' .Reply) ,  Reply: 

printsc( 'HOVER  COMPLETE.'), 

asserta(succeed(hover_l)  ) . 

piiase_coinpleted  (hover_l ) 

ood ( ‘ask_time_out Reply) ,  Reply==l, 
printsc( ‘PHASE  hover_l  ABORTED  DUE  TO  TIME 

a^serta (abort (hover_l) )  . 

next_phase(hover_l ) 

suc':eed(hovGr_l )  , 

retras-t  (currGnt^hase(hover_l )  ) , 
assGrca(currencj?hase{search_l ) ) . 

nex t_phase ( hover. .1 ) 

:  -  abort (hover„l; . 

retract (current  .phase (hover_i) > , 
assetta(currentj>ha.^c(go_5hallow) )  . 

(b)  Automatically  Generated  Prolog  Code  tor  One  Phase 


Phase  * 

buiidMissionGraph  ( ) 

{ 

Hover  “phhover_l  =  new  Hover  (20,45,3.134,500); 

p)iHover_.l->specifySuccessors  (phsearch_l ,  phgo_shallowl  ; 


)  //  buiidMissionGraph 

(c)  Automatically  Generated  C++  Code  tot  One  Phase 

Figure  36:  Sample  Mission  Defined  with  (a)  the  Mission-Specification  Language, 
(b)  Automatically  Generated  Code  in  Prolog  and  (c)  C-H-. 
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D.  SUMMARY 


This  chapter  describes  recent  modifications  of  the  Phoenix  strategic  levek  and  the 
implementation  of  a  mission  planning  expert  system.  Recent  development.*-,  in  the 
execution  and  tactical  levels  of  the  RBM  implementation  on  the  Phoenix  AUV  have 
facilitated  significant  improvement  at  the  strategic  level  as  well.  These  improvements 
include  the  simplification  of  the  strategic  level  through  redistribution  of  responsibilities 
among  the  three  RBM  layers,  definition  of  a  finite  number  of  phase  types,  the  incorporation 
of  phase  parameters,  and  the  development  of  phase  templates.  Additionally,  the  strategic 
level  has  been  equivalently  implemented  m  C++  and  Prolog. 

These  improvements  in  the  strategic  level  have  in  turn  facilitated  the  development 
of  the  mission  planning  expert  system.  The  system  uses  means-ends  analysis  to  generate 
missions  ba.sed  on  goals  specified  by  a  user.  The  system  also  has  a  facility  for  specifying 
missions  one  phase  at  a  time.  This  facility  incorporates  a  rule-based  system  to  insure  only 
valid  missions  are  generated.  Finally,  automatic  code  generation  programs  were  developed 
that  use  the  phase  templates  to  translate  the  output  of  the  other  two  facilities  into  executable 
Prolog  or  C++  code. 

The  following  chapter  describes  experimentation  in  support  of  this  research. 
Attention  is  paid  both  to  experimentation  using  the  UVW  and  the  physical  vehicle. 


Vn.  EXPERIMENTAL  RESULTS 


A.  INTRODUCTION 

This  chapter  discusses  the  experimental  results  of  this  reseai'ch.  The  two  major 
topics  are  virtual  world  results  and  real  world  results.  While  features  were  implemented  in 
the  virtual  world  one  at  a  time  (primarily  in  a  bottom-up  fashion),  the  focus  of  this  section 
is  on  final  results  once  all  of  the  individual  features  were  successfully  implemented  and 
integrated.  This  section  consists  therefore  of  recovery  control  results  and  mission  planning 
system  results.  Mission  planning  expert  system  results  are  treated  separately  because  of  the 
broader  nature  of  that  research. 

Since  not  all  aspects  of  this  research  have  been  verified  through  in-v,'ater  testing, 
simulation  results  are  covered  in  more  detail.  As  stated  in  Chapter  HI,  the  first  area  of  in- 
water  testing  was  hardware  control  verification.  While  all  other  in-water  testing  relied 
upon  proper  software/hardware  interaction,  this  aspect  of  testing  was  not  directly  relevant 
to  the  research  itself.  Success  of  this  aspect  of  testing  is  however  shown  implicitly  by  other 
test  results.  The  primary  focus  of  the  in-water  test  results  portion  of  this  chapter  is  the 
execution-level  behaviors  upon  which  recovery  relies.  In  addition  in-water  results  of 
missions  generated  using  the  mission-planning  expert  system  are  covered. 

B,  VIRTUAL  WORLD  RESUI /rs 

1.  Recovery  Control  Results 

UV'W  tests  indicate  that  the  low-level  behaviors  described  in  Chapter  IV  are 
capable  of  controlling  Phoenix  with  sufficient  precision  to  conduct  recovery  in  a  small 
tube.  Further,  the  path  planning  routines  described  in  Chapter  V  proved  capable  of 
planning  an  acceptable  recovery  path  from  virtually  any  location  into  a  tube  of  known 
pc'silion  and  orientation.  Figures  37  through  42  .show  the  planned  path  and  the  actual  path 
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followed  by  the  vehicle  during  UVW  test  recoveries  conducted  using  tubes  of  various 
orientations.  Missions  for  these  tests  were  generated  using  the  mission-planning  expert 
system  and  use  the  C++  version  of  the  strategic  level.  The  generated  mission  consists  of 
three  phases:  dive  to  depth  (three  feet),  transit  to  a  point  near  the  tube  (-2,-1 5),  and  recover 
in  the  tube  (located  at  (0,  0)  at  the  orientations  specified  in  the  figures).  Running  the 
missions  in  the  UVW  requires  loading  the  Open  Inventor  description  of  the  desired  tube 
(located  in  the  viewer  directory  and  named  tubelangie][neg].iv  for  these  te.sts)  into  the 
dynamics  and  viewer  modules  of  the  UVW.  Occasional  deviations  between  the  planned 
and  performed  paths  are  attributable  to  anomalies  in  the  edge-tracking  behavior  when 
simultaneously  transitioning  between  voronoi  regions  and  sonar  edge-tracking  targets. 
These  anomalies  are  discussed  in  more  detail  later  in  this  chapter. 


Figure  37:  Planned  vs.  Actual  Virtual  World  Recovery  in  a  Tube  Oriented  North. 
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Figure  39:  Planned  vs.  Actual  Virtual  World  Recovery  in  a  Tube  Oriented  Southeast. 


Figure  40:  Planned  vs.  Actual  Virtual  World  Recovery  in  a  Tube  Oriented  South. 


Figure  41 ;  Planned  vs.  Actual  Virtual  World  Recovery  in  a  Tube  Oriented  Southwest. 
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Figure  42:  Planned  vs.  Actual  Virtual  World  Recovery  in  a  Tube  Oriented  Northwest. 

The  most  significant  aspect  of  these  figures  is  that  Phoenix  transited  to  a  point, 
planned  a  recovery  path  into  a  tube  of  arbitrary  but  known  posture,  and  used  automatically 
generated  commands  that  relied  on  low-  level  .sonar  tracking  and  station-keeping  behaviors 
to  follow  the  planned  path  into  the  tube.  Theie  arc  however  anomalies  that  require 
explanation.  Mo.st  notable  are  the  excursions  from  the  planned  path  when  rounding  ctnners 
in  Figure:;  40,  4 1  and  42.  These  excursions  result  from  Phoenix  being  unable  to  distinguish 
the  appropriate  comer  with  the  ST  1 000  sonar  and  therefore  taking  station  on  the  wrong  one. 
When  transitioning  from  the  back  of  the  tube  to  the  side,  the  corner  upon  which  Phoenix  is 
to  take  station  is  the  opposing  back  corner.  Depending  on  the  vehicle’s  orientation,  this 
corner  may  be  masked  by  the  near  corner  when  Phoenix  nears  the  corner.  When  this 
occurs,  the  near  corner  will  be  mistaken  for  the  opposing  corner  resulting  in  an  excursion 
from  the  planned  path  similar  to  the  one  in  Figure  41 .  When  rounding  the  tube’s  front 
corner,  a  similar  phenomenon  can  result  where  Phoenix  mistakes  the  near  eorner  for  the 


opposing  comer  upon  w  hich  it  intends  to  take  station.  This  will  result  in  planned  path 
excursions  as  depicted  in  all  three  figures.  It  is  also  possible  for  Phoenix  to  mistake  the  far 
corner  for  the  near  resulting  in  a  planned  path  excursion  that  will  bring  the  vehicle  closer 
to  the  recovery  tube.  This  type  of  planned  path  excursion  is  significantly  more  dangerous 
than  excursions  depicted  in  Figures  40,  41  and  42  since  the  vehicle  may  actually  strike  the 
tube.  Excursions  of  this  sort  were  encountered  only  during  tests  in  which  improperly  tuned 
control  constants  resulted  in  underdamped  vehicle  response.  In  these  tests  it  was  not 
uncommon  for  Phoenix  to  overshoot  an  intended  station  exposing  a  comer  that  was 
supposed  to  be  masked  to  the  sonar.  A  potential  solution  to  this  problem  might  be  to 
generate  a  desired  range  and  bearing  to  the  center  of  the  tube  rather  than  to  a  comer  of  the 
tube,  thereby  allowing  OOD  module  to  choo.se  the  most  appropriate  comer  for  station- 
keeping  (based  on  Phoenix  cuirent  position  relative  to  the  tube)  and  generating  the 
appropriate  execution-level  command  on  the  fly.  Further  testing  may  reveal  whether  such 
additional  precautions  are  necessary. 

A  second  anomaly  is  the  unreliability  of  recovery  from  starting  points  directly  in 
front  of  (or  behind)  the  recovery  tube.  When  directly  facing  the  opening  of  either  end  of 
the  recovet7  tube,  there  is  simply  not  enough  cross  section  for  the  ST  1 000  sonar  to 
consistently  locate  and  track  a  comer  of  the  tube.  UVW  te.sts  indicate  a  repeating  pattern 
of  locating  a  comer  (sometimes  but  not  always  the  correct  one)  and  losing  track  of  it  almos> 
immediately.  This  problem  does  not  exist  if  the  back  portion  of  the  tube  is  enclosed  (as 
must  be  the  case  for  an  actual  recovery  tube).  For  the  front  portion  of  the  tube,  the  sim.plest 
solution  may  be  to  increase  the  sonar  cross  section  by  adding  a  lip.  Further  testing  is 
required  to  determine  the  size  of  the  lip  required  and  to  make  sure  the  lip  does  not  interfere 
with  tracking  of  the  corner  from  other  directions. 

Finally,  the  figures  indicate  that  Phoenix  is  .slightly  to  the  right  of  the  tube’s  center 
when  entering  (although  clearance  was  maintained  on  both  .sides  throughout  the  recovery 


evolution).  This  is  a  consistent  aspect  of  ail  test  runs.  The  apparent  reason  for  this  result 
is  that  neither  the  ST  1000  nor  the  ST725  is  placed  exactly  on  the  vehicle’s  centerline.  This 
is  not  accounted  for  in  Equation  37.  Slight  modification  to  Equation  this  equations  to  the 
following  is  the  most  likely  solution. 

Thrus!er^^„^^  =  ^(;iru.«fr-™nsf((^5T725*'*’(75°)  +  |>’;772s|)  ~  (^.S'riooo*i**(75°)  +  ly^noool))  (Eq.  56) 
where  and  .\5r1joo  ^re  the  Y  coordinates  of  the  ST725  and  STIOOO  sonars  in  AUV 
body  coordinates  respectively. 

Another  issue  that  should  be  noted  concerning  UVW  testing  and  the  results  shown 
in  Figures  37  through  42  is  the  issue  of  control  constants  for  the  station-keeping  PD  control 
laws.  UVW  testing  has  shown  that  improper  PU  control  constants  will  result  in  a  failure  to 
accurately  follow  the  planned  recovery  path  Thruster  and  proireller  PD  constants  must  be 
tuned  in  such  a  way  that  lateral  and  longitudinal  responsiveness  are  the  same.  Failure  to 
properly  tune  control  constants  will  not  preclude  reliable  recovery,  but  will  result  in 
mediocre  planned-path  following  such  as  that  which  occurred  in  the  test  depicted  in  Figure 
43.  It  should  also  be  noted  that  control  constants  used  in  the  L'sts  depicted  in  Figures  37 
through  42  were  tuned  in  the  UVW.  In-water  testing  descrited  in  the  following  section 
required  retuning  of  the  control  con.stants.  Control  constants  shown  in  Table  3  are  real- 
world  constants.  This  disparity  between  the  virtual  and  real  worlds  highlights  pos.sibly  the 
most  important  area  of  near-  term  future  work;  real-world  validation  of  the  UVW. 
Adjustment  of  coefficients  of  the  UVW  hydrodynamic  model  to  accurately  reflect  the 
actual  hydrodynamic  characteristics  of  Phoenix  is  essential  to  long  tenr.  software 
development  using  the  UVW. 
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Figure  43:  Recovery  with  Poorly  Tl.iiccI  PD  Control  Constants. 


2.  Strategic  Level  and  Mission  Planning  Expert  System  Results 

In  addition  to  the  real  world  and  UVW,  an  interactive  standalone  ood_tes(  program 
has  been  developed  for  strategic  level  testing.  This  program  allows  a  human  acting  as  the 
tactical  level  OOD  to  manually  respond  to  strategic  level  queries  by  querying  a  human 
rather  than  the  tactical  level.  Ixigic  and  sequencing  of  the  strategic  level  (the  stnicturc  of 
the  DFA)  can  therefore  be  evaluated  without  the  AlIV  or  UVW.  In  Figure  44,  the  ood  Jest 
program  is  used  to  debug  an  automatically  generated  Prolog  mission  corresponding  to  the 
mission  ol’  Figure  11.  By  utilizing  the  standalone  strategic  level  and  1 JV W  for  code 
development  and  initial  testing,  and  in-water  testing  for  final  testing  and  validation,  it  has 
been  possible  U)  rapidly  and  siinultaneou.sly  develop  an.d  implement  new  features  at  all 
three  layers  of  the  RBM  architcelure  IBrut/.man  96] 
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Initialization  Complete 

1  Phase  Completed 
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Mission  Complete 

F'igurc  44:  Standalone  Testing  of  a  Mission  Using  the  ood_,test  Program. 

Strategic- level  test  missions  for  Phoenix  have  been  generated  in  both  Prolog  and 
C-(“l-  using  manual  programming,  the  mission-specification  language  and  automatic  code- 
generation  programs,  and  using  the  entire  mi.ssion  planning  expert  system.  The  results  of 
the.se  te.sts  have  been  predictable  and  correct. 

Figure  4.'i  shows  a  graphical  plot  of  a  C-t- 1  mission  created  using  the  means-ends 
analysis  mission  generation  facility.  Goals  for  the  mis.sion  were  to  conduct  sonar  searches 
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from  two  locations  (one  with  specific  routing  to  the  search  point).  When  executed,  the 
mission  conducted  both  sonar  searches,  obtained  GPS  fixes  to  verify  the  search  positions, 
cla.ssified  detected  objects,  planned  a  safe  path  around  detected  obstacles  (object 
classification  and  path  p'anning  were  conducted  at  the  tactical  level),  and  proceeded  to  the 
designated  recoveiy  position.  The  need  for  GPS  fixes  to  verify  search  positions  (as  well  as 
the  initial  dive  to  operating  depth)  were  not  specified  by  the  u.ser,  but  were  executed 
because  oi  die  mca.  .i-ends  analysis  preconditions  and  postconditions  for  the  sonar  .search 
oj^  '’'•ation 


Tigurc  TS'.  UVW  Resulls  of  a  Mission  Gener-ju'd  "i  Urough  Means  Puds  Analysi;;. 


Simplif  ications  made  in  the  structure  of  the  strategic  level  proved  u.sctul.  A  i^iolog 
mission  using  the  new  strategic  level  format  is  approximat'dy  one  third  as  long  as  an 
equivalent  program  manually  prepared  using  the  format  in  place  prior  In  il,e  simplllu  nLions 
described  in  this  paper  [Leonhardt  9bj.  Templates  and  aulomatic  code  generation  proved 
rciiab'e  and  versatile  and  resulted  in  successful  testing  described  here  and  in  |Bnit  '^uin 
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96],  Testing  also  showed  that  it  is  a  fairly  simple  matter  to  accurately  implement  the  RBM 
strategic  level  in  C-h-  using  objects  to  represent  the  nodes  of  the  DFA.  Specifically,  UVW 
tests  showed  that  C-H-  missions  produced  by  the  mission  planning  expert  system  were 
indistinguishable  in  behavior  from  equivale '  it  Prolog  missions  created  by  the  same  system. 

In  general,  manually  coded  missions  have  been  found  to  be  en'or  prone.  Even 
missions  produced  manually  using  templates  or  by  manually  modifying  working  code  are 
still  subject  to  typographical  errors,  errors  of  syntax,  and  logical  errors  in  individual  phases 
or  sequences  of  phases,  any  of  which  result  in  invalid  or  incorrect  missions.  Moreover  the 
increased  magnitude  of  the  Prolog  code  as  mission  complexity  increases  makes  manual 
programming  of  complex  missions  infeasible.  The  slower  growth  of  C-t-i-  program  size 
alleviates  this  problem  only  slightly.  This  result  amounts  to  no  more  than  a  confinnation 
of  previous  results  that  were  a  primary  motivator  of  this  research  work. 

Missions  produced  using  manually  edited  mission-specification  language  files  and 
the  automatic  code-generation  programs  offer  a  substantial  improvement  over  manual 
editing  but  are  still  prone  to  errors.  This  is  because  the  mission  planning  expert  system 
checks  missions  for  validity  prior  to  generating  the  intermediate  mission-specification  file. 
Mission  specification  files  arc  not  checked  for  errors  by  the  automatic  code  generation 
programs.  Therefore,  logical  errors  that  are  otherwise  caught  by  the  mission  planning 
expert,  .system  can  be  inserted  by  the  human  editor  and  processed  by  the  automatic  code 
generation  program  without  complaint,  resulting  in  incorrect  and  unpredictable  mission 
code.  Additionally,  because  the  mission-specification  language  is  significantly  more 
abstract  than  programming  languages,  it  is  somewhat  terse  and  cryptic.  Manually  edited 
mission-specification  language  files  are  therefore  prone  to  typographical  errors  and 
misordered  data  as  well  as  logical  errors. 

Missions  produced  using  the  entire  mission  planning  system  are  easier  to  create 
than  those  coded  manually  or  using  mission-.spccification  files.  They  have  also  proved 


more  reliable,  The  “Florida  mission”  [Marco  96b],  a  complex  mine  search  and 
classification  mission  consisting  of  rcughly  25  phases,  was  produced  using  the  mission 
planning  expert  system  in  approximately  ten  minutes.  A  manually  coded,  version  of  this 
mission  was  originally  generated  and  debugged  over  a  period  of  approximately  two  weeks. 

C.  REAL  WORLD  RESULTS 

1.  Sonar  Tracking  Behaviors 

The  primary  goal  of  in-water  testing  to  date  has  been  the  verification  of  execution- 
level  sonar  tracking  and  vehicle-control  '  -shaviors.  Testing  was  conducted  in  the  Center 
for  AUV  Research  test  tank.  Sonar  tracking  behaviors  were  first  tested  with  the  sonar  at  a 
fixed  position.  Both  the  target-tracking  and  edge-tracking  modes  were  successfully  used 
to  track  a  0,5  meter  diameter  cylinder.  In  this  .series  of  tests,  the  cylinder  was  placed  in 
various  locations  relative  to  the  stationary  sonar.  The  target  .search,  target- tracking  and 
edge-tracking  modes  were  then  used  to  locate  and  track  the  target  for  approximately  60 
.seconds.  Figures  46  and  47  show  plots  of  bearing  versus  time  and  range  versus  time  for  a 
test  during  which  target-tracking  mode  was  used  to  track  the  cylinder  located  on  a  bearing 
of  approximately  70  degrees  at  a  range  of  approximately  1 3  feet  relative  to  the  sonar.  As 
can  be  seen  in  Figure  46,  the  sonar  .scanned  to  the  right  until  reaching  the  target.  At  this 
point  it  scanned  back  and  forth  across  the  target  (a  sector  width  of  approximately  ten 
degrees).  Figure  47  shows  the  range  differential  as  the  sonar  scanned  across  and  off  the 
target  during  its  sweeps.  In  this  plot,  zero  ranges  actually  indicate  that  no  sonar  return  was 
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received. 


Figures  48  and  49  show  test  results  from  static  sonar  tracking  of  the  edge  of  the 
cylinder  located  at  a  range  of  approximately  nine  feet  bearing  approximately  337  degrees 
relative  to  the  sonar.  Figure  48  shows  the  sonar  sweeping  to  the  left  until  locating  the 
target.  At  this  point,  it  begins  sweeping  back  and  forth  across  the  cylinder’ s  right  edge.  The 
sweep  width  during  tracking  is  approximately  eight  degrees.  As  target  size  decreases  or 
range  increases,  the  sweep  width  for  edge  tracking  will  be  very  close  to  the  sweep  width 
for  full  target  tracking.  Figure  49  shows  the  range  vs  time  plot.  Again,  zero  ranges  indicate 
no  sonar  retuni  was  received.  In  this  tests,  the  sonar  located  the  target  and  successfully 
tracked  the  edge  for  a  period  of  60  seconds.  In  this  series  of  static  sonar  te.sts,  both  tracking 
modes  proved  reliable  so  long  as  sufficient  separation  between  the  intended  target  and  the 
test  tank  wall  existed  to  ensure  adequate  range  differential  between  the  target  and  the 
background. 
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Figure  49:  Stationary  Sonar  Target  Edge  Track  Range  v,s.  Time. 

Because  of  the  sometimes  unreliable  nature  of  sonar  data  it  was  occasionally 
possible  to  lose  a  target  that  was  being  tracked.  Figures  50  and  5 1  show  a  portion  of  a  test 
where  a  pair  of  spurious  ranges  caused  the  .sonar  to  lose  the  edge  of  the  recovery  tube  after 
it  had  been  tracking  for  over  90  seconds.  Figure  50  shows  that  between  9b  and  97  seconds 
into  the  test,  two  sonar  ranges  at  approximately  nine  feet  were  obtained.  The  previous  on- 
target  return  was  at  a  range  of  approximately  six,  fc(T,  .so  the  nine  foot  ranges  were  assumed 
to  be  part  of  the  target.  The  subsequent  ranges  wee  accurate  and  represented  the  test  tank 
wall  at  approximately  12  feet,  but  since  the  previous  on-target  range  was  nine  feet,  the  12 
foot  range  was  ahso  assumed  to  be  part  of  the  target.  Figure  5 1  shows  the  sonar  bearing  as 
it  continues  to  sweep  to  the  left  across  the  wall  which  it  believes  to  be  part  of  the  target.  At 
present,  the  only  solution  to  this  problem  is  to  avoid  situations  where  a  spurious  return  will 
cause  loss  of  track.  This  means  that  target  .  must  be  at  least  ten  feet  from  background 
objects  (or  the  range  differential  for  target  discrimination  must  be  red  uced  from  five  feet). 
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Figure  50:  Range  vs.  Time  Plot  Showing  Loss  oC  Track  in  a  Confined  Area. 
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Figure  .5 1 :  Bearing  vs.  Time  Plot  Showing  Loss  of  Track  in  a  Confined  Area. 
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2.  Station-Keeping  Results 

The  next  series  of  in-water  tests  were  intended  to  verify  execution-level  station¬ 
keeping  behaviors.  Tests  were  first  conducted  using  full  target  tracking  and  edge  tracking 
to  maintain  a  series  of  stations  relative  to  the  0.5  meter  diameter  cylinder.  As  UVW  results 
had  indicated,  both  sonar  control  modes  can  be  used  to  navigate  to  and  maintain  stations  to 
within  six  inches.  As  expected,  the  higher  target  update  rates  of  the  edge-tracking  sonar 
mode  allowed  more  responsive  control  than  the  full  target-tracking  sonar  mode  and 
resulted  in  achievement  of  commanded  stations  in  less  than  half  the  time.  Figures  52 
through  54  show  the  results  of  a  test  requiring  Phoenix  to  proceed  through  a  series  of  three 
stations  relative  to  the  cylinder  using  a  full  target  sonar  scan.  In  addition,  the  vehicle 
maintained  the  final  station  for  a  period  of  .'10  seconds.  Vehicle  heading  pointed  directly  at 
the  target  for  the  first  two  stations  and  north  for  the  final  station. 


Figure  52:  Comm.anded  and  Actual  Range  to  a  Cylinder  with  Target  Tracking 
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As  can  be  seen  in  the  previous  figures,  commanded  stations  were  achieved  and 

maintained.  However  time  between  target  updates  was  normally  five  to  ten  seconds  and 

i 

occasionally  as  long  as  20  seconds.  This  slow  update  rate  resulted  in  a  slow  convergence 
with  commanded  range,  bearing  and  heading  and  an  occasional  tendency  to  overshoot. 

While  part  of  this  is  likely  due  to  improperly  tuned  control  con  .ants,  the  fact  that  station 

i 

keeping  using  the  edge-scanning  sonar  mode  converges  upon  the  conunanded  station  much 
more  quickly  indicates  that  the  slow  target  update  rate  significantly  reduces  the  vehicle’s 

ability  to  accurately  control  relative,  to  the  target. 

i 

Figures  55, 56  and  57  show  the  results  of  using  edge  tracking  as  the  basis  for  .station 
keeping.  Stations  were  the  same  as  those  used  during  testing  of  the  full  target  scan  based 

station-keeping  behavior.  Again,  the  vehicle  at  hieves  all  three  stations  and  maintains  the 

4 

third  for  30  seconds.  The  roughness  of  the  range  versus  time  and  bearing  versus  time  plods 
indicates  that  further  luning  of  control  constants  is  required.  The  increased  update  rate  of 

edge  tracking  when  compared  to  target  tracking  enables  Phoenix  to  achieve  each  station  in 

4 

approximately  half  the  time  and  significantly  improves  the  accuracy  of  vehicle  control. 
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Figure  55:  Commanded  and  Actual  Range  to  a  Cylinder  with  Kdge  Tracking. 
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Figure  56:  Commanded  and  Actual  Bearing  to  a  Cylinder  with  Edge  Tracking. 
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Figure  57:  Commanded  and  Actual  Heading  while  using  Fkigc  'lYacking. 

The  final  scries  of  in  water  tests  were  intended  to  test  the  vehicle’s  ability  to 
maneuver  around  the  recovery  tube  in  order  to  position  for  final  recovery.  Because  of  the 
uneven  shape  of  the  recovery  tube,  this  was  a  much  more  difficult  task  than  maneuvering 
about  the  cylinder,  This  test  required  Phoenix  to  travel  through  a  series  of  four  stations 
using  the  edge  tracking  sonar  mode  and  maintain  tlx  final  station  for  a  period  of  60 
seconds.  Heading  was  directed  at  the  corner  of  the  tube  being  tracked  for  the  first  two 
stations,  and  was  aligned  with  the  recovery  lube  for  the  final  two  stations.  The  AUV 
starting  position  was  approximately  1  1  feet  from  the  fror.t  left  corner  of  the  recovery  tube. 
The  final  station  placed  tlic  no.se  of  the  vehicle  just  inside  the  recovery  tube,  f'l  om  this 
position,  recovery  is  possible  using  the  final  recovery  control  mode  described  in 
Chapter  IV.  I^igures  58.  5d  and  60  show  the  re.sults  of  one  of  these  le.sts. 
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I'iyurc  .'iS:  C\iiuniaiided  and  Actual  Range  during  Tube  Station  Keeping. 
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The  ability  of  Phoenix  to  maintain  .station  on  diffciciil  types  of  objects  using  the 
same  sonar  tnicking  and  control  modes  is  clearly  demonstrated  by  these  results.  This 
capability  has  the  potential  to  prove  valuable  not  only  during  recovery  operations,  but 
during  execution  of  various  other  types  of  nii.ssions  as  well. 

3.  .Strategic  l/cvel  suid  Mi.ssion  I'luiining  Expert  .System  Results 

While  the  primary  purpose  of  in-watei  te.sting  in  support  of  this  research  was  to 
verify  execution  level  behaviors  upon  which  further  testing  would  depend,  an  effort  was 
also  made  to  test  iinpiovements  to  the  strategic  level  .software  and  missions  generated  with 
the  mission  planning  expert  system.  In-water  te.sting  of  Prolog  missions  generated  with  the 
mi.ssion  planning  expcit  system  were  eonduelcd  in  the  NPS  sub-Olympic  swimming  pool 
in  March  1996.  Many  of  tlic  results  of  these  tests  can  be  found  in  jlxtonhardt  96).  Missions 
consisted  primarily  of  search  missions  and  missions  that  transited  through  various 
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loratiuns.  Figure  6 1  shows  a  geographic  plot  oCa  search  mission  similar  to  the  one  depicted 
graphically  in  Figure  1 1.  This  mission  was  generated  with  the  phase-by -phase  mission 
specification  facility.  The  mission  includes  two  waypoints,  a  hoverpoint,  a  sonar  search, 
and  a  GPS  fix  followed  by  a  waypoint  and  a  hoverpoint  enroute  to  the  recovery  position. 

Similar  missions  were  generated  for  in-watcr  tests  using  the  means  ends  analysis 
portion  of  the  system  and  also  by  manually  editing  mission  specification  language  files. 
Results  obtained  during  in-water  testing  were  similar  lo  results  obtained  in  the  UVW. 


Figure  61 :  In  Water  Results  of  an  Automatically  Generated  Mission. 


D.  SUMMARY 

Tests  of  features  implemented  during  the  conduct  of  this  research  were  conducted 
in  two  distinct  but  complementary  environments;  the  UVW  and  the  real  world.  UVW  tests 
were  conducted  to  test  features  at  all  three  layers  oi  Phoenix'  RBM  implementation.  These 
tests  using  methods  described  in  the  previous  chapters  re.sultcd  in  successful  recovery  in 


the  tube  in  all  but  a  few  specific  instances.  The  only  failures  occurred  when  Phoenix  was 
initially  positioned  directly  in  front  of  or  behind  the  recovery  tube  and  was  unable  to 
acquire  and  track  a  tube  edge  because  of  the  narrow  sonar  cross  section. 

In  addition  UVW  tests  were  conducted  to  test  modifications  to  the  strategic  level 
software  and  the  mission  planning  expert  system.  These  tests  were  highly  successful  and 
show  that  an  expert  system  for  AUV  mission  planning/generation  is  an  extremely  useful 
tool  that  greatly  reduces  mission  generation  time  while  improving  mission  reliability. 

In  water  tests  were  conducted  to  verify  low  level  sonar  and  vehicle  control 
behaviors.  These  tests  indicate  that  the  sonar  control  modes  described  in  Chaptei  IV  are 
capable  of  reliably  locating  and  tracking  targets  in  the  AUV  environment.  Also,  target  data 
obtained  during  sonar  tracking  can  be  used  as  the  basis  for  maneuvering  relative  to  objects 
being  tracked.  Maneuvering  based  on  target  edge  tracking  proved  to  be  more  responsive, 
but  both  sonar  tracking  modes  were  sticcessfully  used  for  .station-keeping  operations, 
.station  keeping  was  demonstrated  relative  to  a  0.5  meter  cylinder  and  also  a  recovery  tube. 
Station  keeping  relative  to  the  recovery  tube  using  target  edge-tracking  proved  precise 
enough  to  position  Phoenix'  nosi;  in  a  position  from  which  final  recovery  a.s  described  in 
Chapter  IV  was  po.ssible. 

Finally,  missions  were  generated  using  the  mission  planning  expert  system  and 
successfully  executed  in  the  real  world.  Successful  in-water  tests  of  expert  system 
generated  missions  verify  the  utility  of  the  system. 

In  the  following  chapter,  the  conclusions  of  this  re.search  arc  discussed. 
Additionally,  possible  areas  of  future  work  are  outlined.  The  conduct  of  this  research  has 
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also  to  broader  research  goals  of  the  Center  for  AUV  Research  and  other  organizations. 
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VriL  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  LWRODUCTION 

Previous  chapters  of  tliis  thesis  document  the  implementation  and  testing  of 
features  intended  to  support  AUV  recovery  in  a  small  tube.  The  purpose  of  this  chapter  is 
to  dr  aw  conclusions  based  on  the  results  of  this  reseai'ch  and  to  propose  possible  areas  for 
future  work.  The  following  section  di.scusses  conclusions.  The  section  concerning 
recommendations  for  futuie  work  is  divided  into  twelve  subsections.  Each  subsection 
discusses  an  area  for  possible  future  work  that  was  directly  or  indirectly  relevant  to  the 
conduct  and  results  of  this  research. 

B.  RESEARCH  CONCLUSIONS 

The  most  obvious  conclusion  of  this  research  is  that  somu  tai  get  tracking  can  be 
used  as  the  basis  foi  precision  autonomous  underwater  maneuvering.  UVW  and  in  water 
testing  indicate  that  the  precision  of  this  maneuvering  is  sufficient  for  u.sc  tliroughout  a 
recovery  evolution.  Further,  U\AV'  testing  indicates  that  path  planning  and  command 
generation  can  be  implemented  at  higher  levels  of  the  RBM  to  use  lower-level  sonar-based 
maneuvering  to  plan  and  control  recovery  in  a  small  tube. 

A  more  general  conclusion  concerning  the  station-keeping  behaviors  is  the 
applicability  of  sonar -ba.sed  maneuvering  to  broader  mission  areas.  The  ability  to  take 
station  relative  to  arbitrary  objects  will  enable  an  AUV  to  become  an  active  participant  in 
the  environment  rather  than  merely  an  observer.  This  ability  has  potential  applications  in 
many  types  of  missions  that  require  interaction  with  objects  in  the  environment. 
Underwater  filming,  sampling,  repair  and  construction  are  just  a  few  examples  of  potential 
AUV  tasks  that  will  require  this  capability. 
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The  most  significant  conclusion  concerning  the  mission  planning  expert  system  is 
that  the  use  of  a  planning  system  such  as  this  can  greatly  reduce  mission  generation  effort 
and  improve  reliability.  Additionally,  artificial  intelligence  planning  techniques  can  be 
used  to  create  error-free  missions  that  are  guaranteed  to  accomplish  the  mission’s  high- 
level  goals  (assuming  the  goals  are  in  fact  possible  and  no  catastrophic  vehicle  failures 
occur).  It  is  this  research  aspect  that  may  prove  most  beneficial  to  the  field  of  AIJV 
research  in  general.  Only  through  the  succes.sful  implementation  of  easy-to-use  mission 
planning  tools  will  AUVs  evolve  beyond  their  cunent  role  of  academic  and  industrial 
research  projects. 

Another  interesting  conclusion  that  resulted  indirectly  from  this  research  is  that  it  is 
possible  to  satisfactorily  control  a  real-time  system  u.sing  an  unmodified  Unix  operating 
system.  In  Phoenix  RBM  implementation,  hard-real-time  (synchronous)  tasks  are  executed 
on  the  GESPAC  computer  under  the  OS-9  .real-time  operating  system,  while  soft-real-time 
(asynchronous)  tasks  are  executed  on  a  separate  onboard  computer  running  under  the  Sun 
Unix  operating  system.  Hard-real-time  tasks  consi.st  primarily  of  physical  control  of 
vehicle  hardware.  Soft-real-time  tasks  on  the  other  hand,  consist  of  high-level  and 
medium-level  mission  control,  planning,  object  classification  and  navigation.  Most  of 
what  might  be  comsidered  “intelligent”  behaviors  fall  into  the  category  of  these  soft-real¬ 
time  tasks.  By  dividing  tasks  into  hard  and  soft  real  time  categories  in  this  manner,  Phoenix 
control  software  is  implemented  primarily  on  a  system  that  many  might  consider  unsuitable 
for  control  of  a  real-time  system.  The  only  drawback  of  this  system  is  that  it  requires  two 
.separate  onboard  computers  connected  via  L,AN  and  relies  on  BSD  socket  communication. 

Perhaps  the  broadest  and  most  significant  conclusion  of  this  research  results  from 
the  successful  use  of  the  UVW  for  the  implementation  of  vehicle  software.  The  robustness 
of  the  UVW  allowed  for  deterministic  testing  of  vehicle  .software  in  a  benign  environment. 
I'eatures  were  implemented  and  coinprehen.sivcly  tested  one  at  a  time  over  a  period  of 


approximately  one  year  prior  to  in-water  verification.  By  exhaustively  testing  software 
features  in  the  UVW  prior  to  attempting  in-water  tests,  it  was  possible  to  conduct  the  bulk 
of  in-water  testing  documented  in  this  thesis  over  a  two-week  period.  I'he  UVW  is  a 
virtually  unlimited  resource,  whereas  power  supply,  hardware  limitations,  and  logistics 
requirements  limit  the  availability  of  the  phy.sical  vehicle  for  in-water  testing  significantly. 
The  in-water  results  of  this  research  area  depended  heavily  upon  virtual  world  testing  and 
would  have  not  have  been  possible  were  it  not  for  the  UVW. 

While  the  preceding  conclusions  are  significant,  they  amount  to  little  more  than  a 
first  step  towards  recovery  of  AUVs  using  docking  stations  and  submaiines.  A  great  deal 
of  work  remains.  The  reseaich  derailed  in  this  thesis  is  preliminary  in  aature  and  is 
intended  to  begin  dealing  with  issues  involved  with  .self  recovery  of  an  All  V  in  a  confined 
space.  The  following  section  of  this  the.si.s  details  some  of  the  work  that  remains. 

C.  RECOMMENDATIONS 

1.  General  Tactical  Level  Tests  and  Enhancements 

The  most  obvious  ai'ea  for  future  vrork  is  the  verification  of  tactical  level  features 
through  in-water  testing.  While  the  in-water  tests  described  in  Chapter  VI 1  verify  the 
reliability  and  coiTectness  of  the  low-level  sonaj'  and  vehicle,  control  behaviors,  these  tests 
did  not  verify  theii'  use  by  the  tactical  level  for  successful  recovery  control.  Along  the  same 
lines,  the  development  of  tactics  that  use  these  low-level  behaviors  to  accomplish  more 
general  goals  remains  a  topic  for  future  work.  In  particular,  the.se  behaviors  might  be  used 
to  implement  many  of  the  advanced  capabilities  outlined  in  i  Brutzman  96  j. 

2,  Sonar  Tracking  Bella vioi  .s 

The  next  area  of  future  work  involves  improvement  of  the  sonai’  tracking  behaviors. 
As  depicted  in  Figures  50  and  51,  under  .some  circumstances  it  is  possible  for  the  sonar  to 


lose  contact  with  the  tmget  being  tracked.  Even  under  ideal  circumstances  (error-free  sonar 
data  and  a  clutter  free  environment),  it  is  possible  for  AUV  motion  to  cau.sc  the  sonar  to 
lose  track  of  the  intended  target. 

Improvements  in  this  area  fall  into  two  categories:  improvements  intended  to 
prevent  the  sonar  from  losing  contact  with  its  intended  target  and  improvements  intended 
to  enable  to  sonar  to  regain  the  target  in  the  event  of  loss  (which  also  involves  recognition 
of  target  loss).  If  a  full  target  scan  is  used,  features  can  be  extracted  as  the  sonar  sweeps 
across  the  target  as  documented  in  [Marco  96a].  'litis  work  ntight  be  augmented  by  the 
implementation  of  a  simple  letirning  algoritlim  to  “memorize”  target  features  on  the  first 
sweep  to  allow  tracking  of  arbitrary  objects  without  maintaining  a  target  feature  database. 
Successful  implementation  of  this  type  of  system  will  also  need  to  deal  with  issues  such  as 
asymmetric  objects  which  have  different  features  when  viewed  from  different  angles. 
Successful  implementation  of  this  type  of  .sy.stem  to  support  the  faster  edge  tracking  sonar 
mode  might  involve  periodic  sweeps  across  the  enrire  target  to  ensuie  that  the  proper  target 
was  being  tracked  (by  recognizing  and  verifying  the  features  recorded  in  tlie  previous  full 
target  sweep). 

The  computational  and  storage  requirements  of  this  type  of  system  will  doubtless 
neces.sitate  its  implementation  at  the  tactical  rather  than  the  execution  level.  Since  learning 
and  object  classification  are  involved,  placement  at  tlic  tactical  level  is  a  good  match  with 
itleal  RBM  tasking.  Tactical-level  implementation  will  allow  implementation  with 
minimal  changes  to  the  cunent  execution  level  .sonar  modes.  The  addition  of  commands 
to  the  execution  level  command  language  to  enable  switching  from  edge  tracking  to  target 
tracking  for  one  sweep  is  probably  the  only  change  that  is  required  at  tire  execution  level. 


3.  Sonar  Classification 


A  third  area  for  future  work  exists  in  improving  Phoenix’  sonar  classification 
capabilities.  While  a  significant  amount  of  research  effort  has  already  been  directed  at  this 
topic,  current  Phoenix  sonar  classification  capabilities  were  not  specifically  intended  to 
support  recovery  operations.  Sonar  classification  research  to  date  has  been  directed  at  the 
general  case  of  translating  sonai’  data  into  line  segments  and  polygons  representing  generic 
objects  [Bnitzrnan  92,  Campbell  96]  and  the  specific  case  of  classifying  .mine-  like  objects 
[Campbell  96,  Marco  96a].  Complete  implementation  of  recovery  capabilities  must 
include  sonar  classification  of  the  intended  recovery  device.  The  most  straightforward 
implementation  of  this  capability  is  probably  best  performed  by  augmenting  currently 
existing,  sonai'  classification  algorithms. 

4,  AUV  Tracking  and  Control 

While  the  PD  control  laws  discussed  in  this  thesis  lu-e  fairly  effective,  the 
experimental  results  of  the  previous  chapter  clearly  show  that  they  are  far  from  ideal.  In 
practice,  sliding  mode  control  laws  such  as  tho.se  derived  in  [Marco  96a]  have  proven  more 
accurate  and  re.spoiisive  (albeit  more  computationally  expensive)  than  PD  conti'ol  laws. 
Because  of  the  ennent  Phoenix  execution  level  implementation  demands  and  a  weak  60830 
CPU,  the  incorporation  of  sliding  mode  conuol  laws  (for  station  keeping  and  other  control 
modes)  may  be  possible  only  after  optimization  of  the  execution  level  as  described  later  in 
this  section.  A  more  thorough  discussion  of  various  control  modes  and  their  suitability  for 
AIJV  control  during  recovery  can  be  found  in  [Chapiiis  96]. 

In  the  interim  an  effort  to  tune  PD  control  constants  is  neces.sary.  The  present 
Phoenix  execution  level  u.ses  PD  control  laws  for  all  closed  loop  control  modes  (hover 
control,  waypoint  coufrol,  etc.)  and  will  reijuire  tuning  of  constant  teims  of  these  control 
laws  as  well.  U  VW  tests  documeiited  in  the  previous  chapter  demonstrate  that  PD  control 


laws  can  be  used  to  obtain  smooth  motion  along  a  planned  path.  Tuning  of  constants  ba.sed 
on  accurate  Phoenix  hydrodynamics  to  duplicate  UVW  results  duimg  in-water  testing  is 
therefore  possible.  Ideally,  this  work  will  proceed  in  parallel  with  UVW  validation 
discussed  later  in  this  section,  since  accurate  UVW  hydrodynamics  will  enable  tuning  of 
control  constants  without  requiring  in-water  te.sts. 

Similarly,  an  effort  to  ensure  standardization  of  control  law  nomenclature  among 
the  various  Phoenix  conti'ol  modes  is  needed.  This  will  facilitate  the  modification  and 
tuning  of  existing  conu'ol  laws  and  the  implementation  of  new  control  laws  as  well. 

Finally,  improvement  of  the  mathematical  model  used  for  dead  reckoning  between 
sonar  target  updates  is  required.  Errors  introduced  because  of  an  inaccurate  mathematical 
model  lead  to  improper  control  response  that  can  be  counterintuitive  to  diagnose.  This 
phenomenon  was  encountered  on  numerous  occasions  during  the  conduct  of  this  research. 
1’he  six  DOF  model  of  the  UVW  world  demonstrates  that  accurate  mathematical  modeling 
of  AU  V  hydrodynamics  is  possible  and  can  nm  in  real  time.  Improvement  of  the 
mathematical  model  represented  by  Equations  30,  31  and  32  will  improve  many  aspects  of 
the  system  that  depend  on  accurate  vehicle  re.spon.se  in  addition  to  tho.se  documented  in  this 
thesis.  Hover  behavior,  navigation  and  sonar  classification  aie  three  examples.  Ideally,  the 
need  for  a  dead  reckoning  mathematical  model  can  be  eliminated  entirely  by  the 
incorporation  of  an  IMU  as  described  later. 

5.  Ocean  Current  and  a  Moving  Submarine 

Because  of  the  preliminary  nature  of  this  research,  no  real-world  experimentation 
was  conducted  into  the  effects  of  cun'eat  duiing  recovery.  UVW  testing  in  the  presence  of 
a  uniformly  tamstam  ocean  current  pointing  in  an  arbitrar  y  direction  demonstrated  that 
these  control  algorithms  are  robust,  but  before  this  rc.sciU'ch  can  be  applied  in  an 
uncontrolled  environment  such  as  the  open  ocean,  it  will  be  neces.sary  to  research  the 


ini. 


eft] 

( 

to  I 

SU| 

cu 


|i',cts  of  time- varying  cut  rent  during  s  ation  kl 
duding  their  effects  on  control  laws)  need  to 
pcdo  tube  of  a  moving  submarine  wiljl  reqnir^ 
Research  documented  in  ihis  thesis  deali 
tionary  objects  in  a  current- free  enviionmentl 
rents  (as  well  as  target  motion)  are  ij  sues  tii 


6.  Obstacle  Avoidance  Durin 

The  tactical  level  of  Phoenix  cu 
pl:'|inning  and  obstacle  avoidance  for  wa^ 
avhidance  is  not  currently  included  in  tl 
ofthis  tliesis.  Vehicle  safety  during  reco 
Feiabu'es  already  existing  at  the  tactical 
pulh  planning  can  then  use  those  enhan(| 


'  Kecov 
rent  sofi 


:ping  operations.  Flow  field  issues 
be  addressed  in  detail.  Recovery  in  tlie 
the  resolution  of  numerous  similar  is|ue| 
only  with  station  keeping  relative  to 
Nontrivial  .steady  state  and  varying 
t  will  require  significant  research  effcl 


■rv 


ware  implementation  conducts  path 


/points  jind  hoverpoints  [Lconhardt  96],  Obst 


ic  recovery  path  planning  discussed  in  Chaptqv  y 


7.  Sensor  and  Hardware  Issull 
The  most  significant  hardware  i 
re|;i',arch  involved  Phoenix  navigation  s 
dilfcrential  Gl’S  systems  make  up  a  rot 
till  asynchronous  in  nature  and  provide 
bi|st  IMcClarin  96|.  The  asynchronous 
nelccssitates  the  use  of  the  dead  reckoni|h 
lelil  time  navigation  between  .fixes.  Th 
soiitiewhat  wlicn  the  longitudinal  rnotiorj 
sepund,  but  even  in  thi.s  instance,  the  la 
(ej;;.,  using  the  sideslip  model  di.scussci| 


ys 
isues  en| 
(■/stems, 
list  navi 
iiavigati 
nature  c 
g  math 
|;  turbo-] 
of  the  V 
oral  mo; 
1  in  Cha 

11 


ts 


ic| 


■CC 


very  )p«  rations  requires  that  this  issue  be  resol 
evel  wi  I  adapt  fairly  easily  to  this  role.  Reco|'cij| 
cd  feati  l  es  to  plan  an  obstacle-free  path. 


an 


•ountered  during  the  conduct  of  this 
While  the  Divctracker,  GPS  and 
.pttional  suite  by  most  standards,  lhc>| 
)nal  u|.i<lates  (fixes)  every  few  seconc|s  a 
r  htudware  derived  navigational  data 
■matical  model  described  Chapter  TV 
Hobc  speed  wheel  mitigates  this  prob 
•hide  exceeds  approximately  0.25  fed  pt] 
ioji  of  the  vehicle  rnu.st  be  accounted 
)tcr  VI). 


for 


en 


I  or 


As  previously  mentioned,  the  mathematical  model  currently  in  use  contains 
inherent  errors.  Even  a  f.m’  more  robust  mathematical  model  is  unlikely  to  account  for 
external  disturbances  such  as  wave  nrotion  or  uneven  current  effects.  Navigational  errors 
introduced  by  the  mathematical  model  have  a  significant  negative  impact  on  all  vehicle 
functions  that  rely  on  accurate  navigational  data.  Among  these  are  hover  control,  waypoint 
control,  path  planning,  obstacle  avoidance  and  object  classification. 

Research  is  currently  ongoing  into  incorporating  an  IMU  into  Phoenix  [Bachman 
96,  McGliee  95].  The  successful  implementation  of  accurate  real-time  navigation  using  an 
IMU  is  critical  to  many  Center  for  AUV  Re.search  goals. 

8.  Strategic  Level  Enhancement 

A  po.ssibility  for  Future  work  le  RBM  .strategic  level  includes  porting  to  other 
language.s  such  as  Ada95  (including  tlie  development  of  jthasc  templates  and  automatic 
code  generation  programs)  [Holden  95].  Additionally,  work  to  be  conducted  at  all  three 
levels  of  the  RBM  will  involve  the  expansion  of  the  suategic  level’s  primitive  goal  .set  and 
execution  level  command  language  (Brutzman  96].  Pre.sent  primitive  goals  primarily 
support  search  missions.  Future  improvements  miglit  support  run-time  communication 
between  Phoenix  and  ns  support  platform,  dynamic  mi.s.sions  that  can  be  modified  as 
directed  by  the  support  platform,  and  mote  versatile  interaction  with  located  underwater 
objects  (e.g,.,  mine  neutralization). 

It  may  also  be  possible  in  the  near  future  to  implement  a  more  dynamic  strategic 
level  that  is  capable  of  constructing  portions  of  tlie  DFA  at  run  time.  Tliis  might  jirove  to 
be  a  very  u.seful  feature,  particularly  given  the  unpredictable  nature  of  the  marine 
environment.  'Hie  previously  'ddressed  shortcomings  of  the  ineaiis-eiids  analysis 
algorithm  (particularly  those  concerning  non  optimal  solutions)  may  preclude  its  use  in  this 
manner.  However,  another  planning  algorithm  such  as  .search  redutUion  through  least 


commitment,  dependency-directed  search,  nr  meta-level  planning  [Tate  90a  j  may  prove 
more  applicable  in  this  area.  Planning  systems  such  as  Tweak  [Chapman  9()[,  M01.,GF,N 
[Stefik  90|,  NONLIN  [Tate  90b[,  DEVISER  [Vere  9()[,  and  FORBIN  [Dean  90|  for 
example,  address  both  the  efficiency  and  the  temporal  aspects  of  their  .solutions.  Other 
issues  to  be  dealt  with  before  this  type  of  self-modifying  system  is  po,ssiblc  include 
missions  of  nondeterministic  length  and  goal  prioritization, 

9.  The  Mission  Planning  Expert  Sy.steni 

Possible  future  work  might  also  be  d^'^etded  at  improvements  to  tlie  mi.s\sion 
planning  expert  system.  Obviously,  as  the  functionality  of  Phoenix  evolves,  the  mission 
planning  expert  system  will  need  to  evolve  to  take  advantage  of  new  vehicle  capabilities. 
Additionally,  work  is  ongoing  to  simplify  the  pha.se  by-phase  mission  specil  ication  portion 
of  the  .system  and  to  improve  the.  automatic  mission-generation  portion  of  the  system. 
Ideally,  the  meuns-ends  analysis  algorithm  will  evolve  to  allow  automatic  generation  of 
mi.ssions  that  take  full  advantage  of  the  DEA  structure  of  the  stiatcgic  level.  II  die 
automatic  mission  planning  is  enhanced  sub.staniially,  it  may  be  po.ssible  to  completely 
eliminate  tlie  phase-by-phase  specification  portion  of  the  system  without  sacrificing 
flexibility.  Other  planning  sysicms  including  fnose  mentioned  asiKissible  run-time  mission 
planners,  may  prove  useful  in  this  area  as  w'cll.  Modifications  that  may  be  applicable  in  the 
sliort  tei  Ill  include  modifying  the  pliasc-by-pha.se  specification  facility  to  incorporate  error 
correction  rather  than  simple  error  detection. 

One  potential  mission  planner  iiiiplemciitalion  might  involve  a  combination  of 
means-ends  analysis  witli  another  search  technique.  For  instance  by  as.'.igniiig  co.sts  to  the 
application  of  each  operator,  it  is  possible  to  detcniiiiie  the  total  cost  of  a  solution.  If  a 
hybrid  means  ends/searcli  algorithm  is  applied  in  parallel  to  find  operation  sequences 
satisfying,  each  top  h‘vcl  goal,  the  co.sts  of  e.ach  partial  .suhitinn  can  be  coinpaied.  By 
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choosing  the  lowest  cost  option  and  reapplying  the  algorithm  to  the  remaining  goals 
(starting  from  the  end  state  after  application  of  the  low-cost  paitial  solution),  a  sequence  of 
operations  can  he  generated  to  accomplish  all  of  the  goals.  This  strategy  amounts  to  a 
combination  of  nu-ans-ends  analysis  with  best-first  search  [Winston  92].  Other  search 
strategies  may  be  useful  in  this  sort  of  implementation  as  well. 

h'inally,  the  current  version  of  the  mission  planning  expert  system  is  depeiulent 
uptrn  the  availability  of  Quintus  Iholog  ai’d  Prowindow.s.  Possible  future  work  to  permit 
cross-platform  independence  includes  porting  the  expert  system  to  an  H  TML  interlace  that 
can  he  run  across  ti  compuu  i  network.  Sucli  a  system  would  ]rrobal)ly  involve  a  seiA'ci- 
based  script  that  executes  queries  ag  inst  the  rule  base.  Since  such  a  system  can  be  run 
from  any  platform  using  any  web  browser,  such  an  apjrroach  (troviiies  complete  |)latform 
and  window  system  independence. 

1(1.  Operating  System  Issues 

One  of  the  conclusions  drawn  earlier  in  this  chapter  is  that  it  is  possible  to  control 
a  real-time  system  using  a  standard  Unix  oiKTating  system.  This  does  not  however  mean 
that  it  is  necessarily  desirable.  'I'hc  requirement  of  two  computers  and  the  n-liance  upon 
network  communications  may  justify  the  transition  to  a  single  coinpnter  running  a  real-time 
operating  system  such  as  VxWorks  [Wind  River  .Systems  9.51.  On  the  other  hand,  sinee  the 
e.secution  level  is  not  multi  tlire.ided,  it  may  lx‘  possible  to  control  even  tlic  luud-rcal-time 
tasks  Iry  using  a  dedicated  processoi  mniiing  a  slaiidard  o|)craling  system  such  as  Unix 
This  implementation  still  requires  at  least  two  onboard  computers.  As  l)otli  of  these 
alternatives  arc  worth  looking  into,  a  comparative  study  m;iy  lead  to  interesting,  and 
insightful  conclusions  that  will  lie  relevant  to  ;i  number  of  areas  in  addition  to  Al )  V 
re  .search. 
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Another  operating  system  issue  involves  the  concurrent  process  implementation  of 
the  tactical  and  strategic  levels.  Fhe  Unix  version  under  which  the  cunent  system  runs 
does  not  support  shared  memory  between  .separate  proces.ses  even  when  they  arc  forked  by 
a  common  process  [Stevens  92  j.  This  shortcoming  necessitates  the  u.sc  of  Unix  pipes  for 
interprocess  communication,  New-er  versions  of  the  Unix  oiterating  system  now  support 
shared  memory  [McKusick  96j.  It  may  be  worthwhile  to  rewrite  the  communications 
IHirtions  of  the  tactical  level  to  use  shared  memoiy  for  some  communications.  This  might 
improve  the  efficiency  of  the  tactical  level  and  may  prove  more  readable  as  well.  While  it 
is  probably  impractical  to  replace  all  inteqnocess  communication  with  shated  memory, 
maintaining  a  single  copy  of  the  vehicle  state  vector  as  opposed  to  one  copy  for  each 
tactical  level  module  might  prove  veiy  beiu.ficial  A  similar  nirgradc  ol'  the  strategic  and 
tactical  levels  that  addres.ses  the  .same  issues  might  be  their  implementation  in  an  inherently 
multi  threaded  computer  language  such  as  Ada9.5  [1  lolden  9.51. 


1 !.  C'ode  Optinii/atioii 

Numerous  features  have  been  added  to  .Ml  three  layers  Hlrnc.iix  RHM 
im|iletnentation  during  the  conduct  of  this  ;ind  other  research.  While  these  new  features  are 
quite  robust,  little  effort  has  been  expended  to  ensure  efficiency  of  the  overail  system.  As 
a  result,  the  execution  level  in  panicular  is  only  capable  ol  maintaining  a  synchronous 
.speed  ol  Just  over  five  Hert/.  [  Burns  96 1,  While  this  .speed  appears  adequate,  it  leaves  little 
room  for  future  enhancements,  'fhe  two  possilile  solutions  are  the  methodical  oplimizatiuii 
of  source  iirograms  or  an  upgrade  of  execution  level  computer  hardware  (which  likely  will 
require  a  software  rewrite  anyway). 

While  tile  tacticiil  level  does  not  c  urrently  sulfer  trom  inefiicie.ncy  to  a  ;  great  a 
degree  as  the  execution  level,  oiitimi/.ation  is  still  possible.  At  the  strategic  level,  however, 
readability  is  considered  more  impoitant  than  efficiency.  I’liis  coupled  with  the  lelalively 


<9) 


J(r 


4 


« 


•  • 


« 


small  size  of  strategic  level  programs  makes  optimization  of  this  software  layer 
unnecessaiy. 

12.  Underwatt  Virtual  World  Improvement 

A  final  area  for  possible  future  work  is  improvement  of  the  U  VW.  As  discussed  in 
the  previous  section,  the  UVW  proved  to  be  an  invaluable  tool  during  the  conduct  of  this 
research.  Validation  of  the  UVW  by  using  real-world  data  to  tune  hydrodynamic  model 
coefficients  will  make  it  even  more  valuable.  Tuning  of  control  constants  based  on  an 
invalid  vehicle  response  model  inevitably  leads  lo  contro'  problems  that  are  cxticinely 
difficult  to  diagnose  due  to  the  large  number  of  coefficient  and  var  iable  terms  in  most 
conu'ol  laws.  Problems  of  this  sort  encountered  during  this  ic.search  included  botli 
overdamped  and  underdatnped  control  law  coefficients.  Conrplete  valiilaiimi  aird 
verification  of  all  vehicle  hydrodynamic  response  parameters  is  cssenrial  to  tlur  accurate 
modeling  required  for  development  ot  reliable  coirtrol  respon.se.  This  is  easily  the  most 
imirortanl  area  of  research  concerning  the  UVW  .since  improving  the  accuracy  of  vehicle 
response  in  the  UVW  will  have  a  dramatic  effect  on  the  reliability  of  developed  softwaie. 

Another  possible  area  of  work  concerning  the  UVW  is  the  translation  of  the  viewer 
from  ('++  and  Open  Inventor  to  Java  [Go.siing  96|  and  the  Virtual  Reality  Modeling 
Language  version  2.0  (VRML,)  [VRML  Repo.sitory  96].  1'ran.slation  of  network  code  to 
Java  and  graphics  code  to  VRML  will  allow  u.se  rrf  the  UVW  on  any  platform  u.siiig  a 
VRML-ct)nipatibie  web  brow,sc,r.  It  will  also  facilitate  the  sharing  of  world  models  by 
allowing  ol'jccts  to  be  imported  into  the  UVW  from  anywhere  on  the  bitcniet. 

I).  SUMMARY 

This  chapter  di.sciisses  conclusions  drawn  ba.sed  on  this  re.scarch  and  possible  areas 
for  future  work.  The  first  major  co'  elusions  of  this  work  are  that  it  is  possible  lo  use  o.nar 
infoi  inalioti  as  the  basis  for  precision  maneuver  ing  of  an  AUV  and  that  higher  level 


behaviois  can  use  this  capability  to  control  recovery  operations.  Adnitionally,  precision 
maneuvering  based  on  sonar  data  can  be  implemented  in  a  general  enough  way  to  facilitate 
its  use  during  various  portions  of  a  nrission.  It  was  further  concluded  that  a  mission 
planning  expert  system  is  an  invaluable  tool  for  the  rapid  develo|)nient  of  comjrlcx  missions 
that  arc  free  from  errors  and  accomplish  the  mission's  goals.  Possibly  the  most  imp  'i  tant 
cunclusioii  drawn  from  this  research  is  the  value  of  the  UVW  lot  rapid  development  and 
testing  of  vehicle  softwtire 

During  the  conduct  of  this  research,  numerous  areas  for  potential  future  woi  k  were 
encountered.  Fir.st  is  tlie  development  and  in  water  verification  of  tactietd  level  behaviors 
that  rely  on  the  sontir  and  vehicle  conuol  behaviors  described  in  this  thesis.  Otlier 
possibilities  directly  related  to  furthering  tliis  re.se:ircli  tireti  ;tre  tlie  enhtincement  oi’the 
sonar  tracking  behaviors,  sonar  classificiition  direc  ted  at  identitiealioii  of  the  recovery 
device,  iinprovenieats  to  the  eunent  PD  control  laws  and  dead- reckoning  matlicmatical 
model,  and  dealing  with  ocean  current,  moving  targets  and  unexpected  obstaelcs  during 
recovery  ojterations.  b'onecrning  the  strategic  level  and  tlie  mission  planning  exjicrt 
system,  po.ssible  fttluie  wink  includes  implementation  of  a  more  dynamic  strategic  level 
capable  of  limited  run  time  phinning,  iminovement  of  the  tiutomatie  mission  generation 
and  pha.se-  by-pha.se  mission  specification  facilitie.s,  and  porting,  of  the  expert  sy.slem  to  a 
platform-independent  .server  liascd  architecture  accessible  from  the  intenie.t.  l  uially,  more 
general  areas  of  possible  future  work  iticlude  a  compari.son  of  real  time  and  .standtird 
operating  systetns  for  AIJV  -ontJol,  optimization  of  the  execution  and  tactical  level 
programs,  validating  the  UVW  based  on  real  world  data,  and  ultimately  conversion  of  tlie 
[ )  VW  vii  wer  to  .laea  and  VKIV11 , 
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APPENDIX  A.  OBTAINING  ONLINE  RESOURCES 


One  of  the  Naval  Postgraduate  School’s  primary  missions  is  to  conduct  research  of 
value  to  the  militaiy  and  public.  The  Center  for  Autonomous  AUV  Research  makes  all  of 
its  significant  work  available  online.  Via  the  Internet,  copies  of  all  current  software  which 
is  used  to  mn  Phoenix  or  the  underw'ater  virtual  world  are  available  for  downloading.  Other 
items  available  include  graphics  images,  photographs,  master’s  the.ses,  Ph.D.  dis.sertations, 
brieiings,  personnel  listings,  and  other  information  relating  to  AUV  research  at  NPS. 
Il.eonhardt  96] 

An  electronic  mail  (e-mail)  group  {uuvrg(^cs.n[)s. navy. mil)  is  used  to  di.su-ibute 
message  traffic  to  all  members  involved  in  the  research  group.  Interested  individuals  group 
can  subscribe  to  the  e-rnail  group  by  filling  out  a  request  fonn  which  is  available  on  the 
Center  for  AUV  Research  World  Wide  Web  site  (hlip.ilwwiv.iw.npsjiavy.milire.scarchl 
auv).  jLeonhardl  96] 

Files  for  the  software  can  be  downloaded  individually  or  as  a  complete  compressed 
archive  package.  In  addition,  numerous  sample  missions  written  in  Prolog,  C++,  and  the 
execution  level  .scripting  language  arc  included.  The  complete  download  and  in.slallation 
instructions  are  available  at  the  Softw'are  Reference  site 

{hiq)  .  Uwwvxstl.nps. navy  .mil! -brutzmunldL'isertaiumLsoftware  referciire.h!m\  ).  I  'he  si/e 
of  the  complete  iincompresserl  archivi  is  approximately  15  MfU 
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APPENDIX  B.  EXECUTION  LEVEE  COMMAND  LANOUACE 


This  appfiidiy  Lontaiiis  the  niission.scripi.HEI  ,P  filt*,.  This  1'ile  describes  the  syntax 
oh  the  execution  level  language.  This  language  is  used  to  construct  mission  script  I'iles  that 
can  be  read  by  the  execution  level  or  tactical  level  process  to  execute  a  scripted  mission. 
Additionally,  this  language  is  insed  by  the  tactical  level  to  direct  the  execution  level  in  order 
to  accomplish  strategic-level  goals.  Finally,  this  language  can  be  used  interactively  and 
entered  from  a  commanti  line  to  control  the  AIJV  using  one  command  at  a  lime.  The 
mission. script. HELP  file  also  contains  instructions  on  how  to  construct  and  use  mis.sion 
.script  files.  This  file  is  available  online  at 

hTip:!iww\vMl.nj)s.na\'y.mill~l)nitzn\anldisseftatii>iil.':()fiwnre  referencirhiml 

I'his  file  is  available  individually  or  as  part  ol  the  .tar  package  comaining  all  Pluu'nix  and 

UVW  soltv/are. 


// 


// 


(*' 
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mission  .  script' -HELP  12  August  96 

Mission  script  syntax  for  NPS  AUV  axecution  level  and  tactical 

control,  in  water  and  in  the  NPS  AUV  Underwater  Virtual  World.  • 

http ;  /  /WWW.  stl ,  ups  .navy  -mil/~auv/execution/mic.sion.  script  .HELP 
Don  Brutzman  brut zman@nps .navy .mi  1 
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This  tile  describes  how  to  chanye  and  -creare  NPS  AUV  mission  script  files. 

Example  mission . script  files  and  the  'execution'  program  arn  in  the 
'-/execution  subdirectory. 

Script  commands  are  received  by  the  AUV  execucion  level  (execution. c)  from 

Che  tactical  level  during  a  mission,  the  operator  at  the  keyboard,  or 
read  from  the  'mission .  script  *  file.  Both  tactical  and  e.xecurion  can 
carry  out  mission  scripts. 

To  lun  a  new  mission,  copy  a  different  existing  mission  file  over  file 

•  mission .  script '  or  edit  the  mission. script  file  tor  a  nev;  mission. 

Example : 

Unix."  hd  exccucion 

unix>  cp  mission. script. siggraph  mission . script 
unix>  execucion  virtual  fletch.cs.np3.navy.mil 
or 

unix>  execution  virtual  fletch  mission  mission . -icripu  .  siggraph 

Many  ot  the  following  con.mands  will  also  work  when  invoked  troin  the  command 

line-  upon  execucion.  Detailed  coitunand  line  guidance  ii!  also  available 
interactively  using  the  online  NPS  AUV  process  launchm  form  at 
http , //blackand.scl . ups .navy . mi l/-auv/ launcher/ launcher .cgi 

Nunierous  script  keywords  (and  synonyms)  are  currently  recognized.  We  have  been 
generous  in  the  use  ot  synonyms  in  order  to  reduce  the  possibility  of 
catastrophic  spoiling  errors.  This  approach  might  bo  further  extended 
to  include  synonyms  in  other  languages  (French,  Porf.iguesi^  etc.) 

Hint  h.  nc  ! 

Sections  in  this  syntax  help  file: 

Helm  comniands:  open- lo-ip  and  closed-loop  control 

-  Naviga.iion  commands 

-  Missior.  timing  commands 

Mission  setup  and  confiyuratiou  commands 

-  Sonar  commands 
Miscellaneous  commands 


4 


4 


kcyv.'-ords  1  Parameters  t  nps':r:ription 

Synoi.yms  I  (optionall  I  (all  un.i  cs  are  feet,  degrees  or  seconds  as  appropriate; 

.  ( —  ■  + - -  - - -  —  - 

i  I 

I  I 


/,  Helin  r:oiimiands:  open- loop  and  closed- loop  control  - 


KPM 

# 

1  #tt  1 

S'lL  ordered  rpm  v.aluos  to  (t 

n 

[#iti 

[  or  independent Jy  set  left 

PRopr; 

Itut] 

Lc  #  and  #«  respec r i voly 1 

I'RCPKLI.OR;; 

H 

1  (t#  1 

maximum  propel  lot  speed  is 

for  both  piopcllorc 
h  r ight  tpm  values 

-  700  j-piTi  r>  7.  II /sec 


// 


« 


41 


« 


f 


« 
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4 
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Enable  vertical  and  lateral  thruster  control 


THRtJSTERS-ON 
THRUSTERS 
THRUSTEROM 
THRUSTERSON 

NOTHRUSTER  Disable  vertical  and  lateral  thruster  control 

NOTHRUSTERS 

THRUSTERS-OFE 

THRUSTERSOFF 

RUDDER  #  Force  rudder  to  remain  at  #  degrees,  thrusters-ot f . 

Value  is  for  after  rudder,  negative  command  turns  left. 

DFADSTICKRODDER [ # 1  Force  rudder  to  remain  at  0  [or  #)  degrees, 
thrusters-  of  f . 

COURSE  #  Set  new  ordered  course  (commanded  yaw  angle) 

HE,\DTNG  # 

YAW  tt 

TURN  %  Change  ordered  course  by  #  degrees 

CHANGE COURSE  #  (positive  it  to  Starboard,  negative  S  to  port) 

PLANES  it  Force  planes  to  remain  at  #  degrees,  tnrusters-of  f - 

Value  is  for  .ifter  planes,  negative  command  points  down 

DEADSTlCKFL/iNES  (tt )  Force  planes  to  remain  at  0  (or  it|  degrees, 
thtusters-of f  . 

DEPTH  #  Sot  new  ordered  depth  iconunanded  z) 

PITCH  tl  Set  new  ordered  ()j.tch  (conmianded  theta  aayje)  . 

THETA  #  Only  effective  during  HOVERCONTROI, . 

ROTATE  K  open  loop  iacerai  thritster  rotation  control 

at  tt  degrees/sec 

NORO'fATE  liisable  open  loop  lateral  thruster  rotation  control 

ROTATEOFF 

ROTATE  OFF 

LATERAI, 


NOLATERAL 
I.ATERAl.OFF 
LATERAL -Ol'E 

//  Navigation  commands - -  - -  - -  - -  . - 

lUVETRACKER  1  it  ##  tt#tt  I’os  i  1 1  on  ot  DiveTracker  tran.sducer  1 
DIVETRACKERS  tt  it#  #it#Position  ot  DiveTracker  Ci.insdacet  2 

Still  need  to  incurporate  bearing  to  Di veTrackers . 

Proceed  to  shallow  depth,  take  Global  Pcsitioniag 
Sy'steiu  (Gl’.S)  t  V. ,  L  eSt'Jit:  Oi  ilei  t-\]  tlOutli  wljtij  Ooiit  . 
Control  (thtii:;!  I'l  propel  Jers/plancs,  combined) 
is  not  modit  leil.  MaKunnui  fix  time  is  to  seconds, 
nr  which  rune  exc- -nr  '  on  relu-m  to  previousiy 
ni  tlere,.!  depth. 

cne  .('[Mpj  [-pn  jjx  coirplete,  i  esuiiic  previtms.ly  oi'dero'l  deplh. 

Cl’S  FIX  COMPLETE 

lit’qi  c’  s  ot  ctror  iiioasiiretl  for  qy  raconip.is  ; . 

If.YKO  I  ERROR  TRUE] 


GPS 

C,  P.O  F  I  A 
GPS -FIX 


(t  open  loop  lateral  thruster  translation  contioi 

at  ft  ft /sec 

(positive  is  to  starboard,  maximum  is  0,5  ft/sec) 
disable  open  loop  lateral  thruster  translation  control 


GYRO  ERROR 
GYROEKROR 


U 

tt 


DEPTH-CELL-BIAS  # 
DEPTHCELLBIAS  # 
DEPTH -CELL  ERROR  # 
DEPTiiCELLERROR  # 


Feet  of  bias  rror  measured  for  deoch  cel  i . 
[DEPTH  CELL  Z  -c  BIAS  TRUE  2] 


POSITION 

LOCATION 

FIX 


#  ##  [###] reset  vehicle  dead  reckon  position  to  (x,  y)  or 

#  ##  I###) (X,  V-  z!  =  i*.  ♦*-  *##)  at  current  clock  time 

tt  (tt*  ((tStlThis  is  a  navigational  position  fix.  Receipt  of  a 
FOSITION/LOCATION/FIX  command  resets  the  execution 
level  dead- reckon  position.  Note  that  depth  value  z 
will  likely  be  reset  by  depth  cell  if  operational. 


ORIENTATION  #  ##  ###reset  vehicle  orientation  to 
ROTATION  #  ##  ###(phi,  theta,  psi )  =  (♦,  ###) 


POSTURE  #a  #b  #c  #d  #e  #f 

reset  vehicle  dead  reckon  posture  to 

(X,  y,  z,  phi,  theta,  psi)  -  (#,i,  #b,  #c ,  #d,  #g,  ttti 

OCEANCURRENT  *x  #y  [ttz]  Ocean  current  rate  along  .North-axis,  East  axis  and 
OCEAN  CURRENT  #x  #y  [szl  [Optional)  Depth-axis  (feet/sec) 

(this  is  cartesian  version  of  .set  and  drift) 


WAYPOINT  #X  #Y  [#Z]  t#rpml 

WAYPOINT-ON  ttx  #Y  (42)  (4tpml 

Point  towards  waypoint  with  coordinates  (#X,  4Y) 
(depth  #Z  optional)  (speed  #rpm  optional).  You  can 
leave  waypqint  control  by  orderliici  course,  rudder, 
si iding- mode,  rotate  or  lateral  thruster  control. 


If  in  TACTICAL  mode,  execution  rtiports  STABLE  when 
waypoint  is  achieved. 


STANDOFF  4 

STAND-OFF  4 

STANDOFFDISTAWCE  « 
ETANDOr F -  DISTANCE  4 
.'ITAND ■  Ot'K  ■  DISTANCE  4 


Change  standoff  distance  fot  WAYPOINT- FOLLOW  and  HOVE.R 
control 


HO'.’ER  I  4X  »Y;  !4;’.1  Hover  using  thrusters  and  propellers  tor  longitudinal 

and  Jateial  positioning  at  specified  or  prevLour 
waypoi nt 

HOVER  (  4X  4Y|  ( #7. 1  ( t>or ientalion)  ( 4standof  £-di stance ) 

Uses  WAYPOINT  control  until  within  #si  .mdof  f -d.i  stance 
of  HOVER  point  (4X,  4V,  42),  then  sw.iii'he.s  to 
HOVER  control  with  (opi'onalj  linal  toiientation 

Full  speed  (700  RPM)  port;  k  starboai  .1  is  need  if 
AUV  distance  to  WAYPOINT  i.c  >  4standor f  -di  stance  t  10', 
then  slows  to  200  RPM  until  within  4standof f -distance, 
then  HOVER  control. 


HOVER  witheut  parameters  is  the  p'-ef erred  method  of 
slowing  since  backing  down  with  negative  propellers  may 
result  in  large  sternwav  and  .-revere  depth  excursions. 

If  in  tactical  mode,  execution  iiiports  CTABLE  when  done. 


HOVEROFF  Turn  off  HOVER  mode 

liOVEH  OFF' 

HOVER  OFF 


TARUETHTATiaN  4R  4B  [4Psi| 

T.AP.HKT  HTA'i'ION  FK  4B  f4l>c:i| 

Hover  relative  'o  a  sonar  large!  at  r.ui'ie  -  ttu  and 
l-'rgi.H  bearing  4H  fioiii  rli(‘  AUV.  (.'oimii-ani lei.i  AUV 


1.12 


-V 

,  'ir  - 


« 


< 


4 


#  < 


< 


« 


4 


heading  is  #P3i  (detaulL  is  point  at  target )  . 
Stationkeeping  wil  1  use  full  target  i  rackiiig 
sonar  mode 

TAJIGEI'STATION  #R1  *B1  #R2  #B2  (4*Psil 
TARGET -STATION  #R1  #B1  #R2  #B2  l#Psil 

Hover  relative  to  sonar  target.  Target  currently 
at  range  -  #R1,  bearing  #B1  from  AUV.  Coitunanded 
range  =  *R2,  commanded  bearing  -  ltB2,  commundad 
heading  -  itPsi  (default  is  point  at  target), 
scat ionkseping  will  use  full  target  tracking 
sonar  mode 

EDGESTATICN  #R  #B  (#Psil 

EDGE-STATION  ttR  #B  l#Psi] 

Hover  relative  to  a  sonar  '■  arqet  at  range  =  #R  and 
target  bearing  ftB  from  the  AUV.  Commanded  AUV 
heading  is  (tpsi  (default  is  point  at  target)  . 
Stationkeepiiig  will  use  full  target  Cracking 
sonar  mode 

EDGESTATIO.I  !tRi  ttB '  (*R2  #B2  (ttPsi) 

EDGE -STATION  ftRI  itB  #R2  #B2  [KPsil 

Hover  relative  to  sonar  target.  Target  currently 
at  range  -  #R1,  bearing  461  from  AUV.  Commanded 
range  ■;  (tR2,  commanded  bearing  --  comm-inded 

heading  --  #Pui  (default  is  point  at  target:  , 
scat lonkeeping  will  uce  target  edge  tracking 
sonar  mode 

TARGET  OFE'  Turn  of  I  st.it  lonkeeping  control  mode 

TARCETOFf 

NO- TARGET 

NOTARGET 

TARGET-POINT  Cotnir.anded  #Psi  during  scat ionkoeping  will  point 

TARGETPCINT  directly  at  target  center 

NO  TARGET  POINT  Commanded  #l':;i  during  scat  ionkeeping  can  be 

NOTARGETPOINT  manually  coni  rolled  using  HEADING  commands 

TARGET- POINT  OFF 
TARGETPOINTOFF 

ENrERTUBE  4  #4  Experlmetu.al  control  mode.  This  tells  execution  level 

ENTER  TUBE  4  44  that  nose  has  entered  the  Cube,  drive  the  rest  of  the 

way  in  using  dead  reel- on  toi  forward  motion  and  sonars 
(pointing  to  opposite  sides)  to  maintain  cube  side  wall 
st.andoCf.  Parameters: 

4  How  fat  forward  to  travel  to  be  Lully  inside  tube' 

44  TMbe  orieritat  i(jn  in  d'-i'.oes 

■‘ /  Mission  timing  command-:  -  - -  -  ■  -' .  . .  ■  . . 


WATT  It  W.n  i  r  (or  run'  tor  #  seconds  llettinq  the  t  otioi  exernio' 

P'  g'  4  pi  iot  to  reading  from  the  script  t;lv-  again 

t  in  inCTJCAI,  mode,  execution  ignores  W.'  IT  coiraiuiiuls 

'"MK  4  Wait  (or  run)  until  robo'  clock  ''imo  4 

WMTUNTII.  4  (letting  tno  t  c^bot  execute  its  cut  rent  ordi-isj 

''AU.nE'UNTI '4  prim  to  reading  1  roin  Lli<’  'icript  fib-  iga  i  n 

If  in  TACTICAh  mode,  execution  icjnorf;  'I'lMK  coiran-aiidr; . 

■I'lME.sTEP  4  -haiigi'  default  execution  level  time  si  0(i  int.ptv.i) 

'I'lMK  GTEP  4  tiom  default  ol  n .  1  oec  to  4  s-'e 


i 


1-1  "5 


4 


9 


STEP 

SINGLE-STEP 

PAUSE 

RPL\LTIME 

REAL-TIME 

NOREALTIME 

NO-REALTIME 

NONREALTIMe 

NOWAIT 
NO-WAIT 
NOPAUSE 
NO- PAUSE 


loop  for  another  cimestep  prior  to  reading  script  again. 
Only  useful  in  execution  keyboard  mode. 

temporarily  scop  execution  until  <encer:>  is  pressed 

run  execution  level  code  in  real -time 

(busy  wait  at  the  end  of  each  timescep  if  time  remains) 
run  execution  level  code  as  quickly  as  possible 


//  Mission  setup  and  configuration  cortunands 


-// 


HELP 

■} 

/? 

_  o 


Provide  a  list  of  available  keywords 
(as  specified  in  this  HELP  tile) . 


comments  follow  on  this  line  which  are  not  executed 
note  comments  will  still  be  spoken  if  AUDIO-om 
pound  sign  also  indicates  a  comment  if  in  first  coiumn 


//  Three  startup  modes : [LOCATIONLAB ) 


TETHERED  I  UHTETHEREU 


LOCATIONLA13 
LOCATION  -IJlB 

TETHER 

TETHERED 

UNTFTHER 
UNTETHEREL 
NOT ETHER 
NO  TETHSB 


Vehicle  is  operating  in  lab  using  virtual  world. 
Thi.s  is  default  mode. 

command  line  switch  only,  used  for  in-water  runs 
.sec  D1SPLAVSCREEN=.TRUE  and  LOCACTIONLAB=FALS’E 

command  line  switch  only,  used  for  iii  waiei  runs 
set  DISPLAYSCREEN=EALEE  and  LOCACTIONLAB^ FALSE 


■'IRTUAL  hosrname  tells  execution  level  to  open  soc)«er  to  virtual  world 

'.  IR'I'OALHi  i.CT  hostii.ame  which  is  already  running  .ind  waiting  on  'hostname' 

!''.EM')TE  li. 1st  name  VIRTUALHOLT  is  a  command  lino  swicc)i.  Example: 

REMUTEHOST  ijostiiame  unix'-  execution  virtualhoat  t  letch  .  st  1  .  nps  .  navy  .mi  1 

riYNAMIc;;  liosLiiame 

TACTrCAI,  hostname  tells  execution  level  to  open  socket  to  Cactica.l  level 
TACTDrALKO.'lT  hostname  which  is  already  running  and  waiting  on  'hostname' 
STRATECIt;  hostname  TACTK'AL/STRATEGIC  is  a  .command  Line  switch.  Example: 
.HTRAT'E' !CHi  j.CT  hor;tnameuriix>  execution  tact  icalhost  fietch .  st  1  .  npe .  navy  .mil 


MIDEtCiM  f  I  lenami- 
.a  Til  FT  fileiidiiu- 
!■'  I  IiK  i  i  1  eiirim*- 

TELEMETRY  1  i  I  eii.iine 


NO.Li'lUP'I' 


K  I-"i  I'OAHli 
KLYnnARli  ON 


[■'Yli' jAIO'  iMT 
N.  ■  KEYFOARL 


Replace  'mission . ocripr  ’  with  'tiiGiiame'  and  start 
Che  new  mission.  Read  tactical  command:;  for  execution 
1  eve]  t  rom  t i 1 ename . 

Playback  prerecorded  teiemetiy  data  from  filename. 
Consider  u.sing  with  NOHCRTPT  if  no  script  file  present, 
dynamics  sf^rld  lio  run  with  selection 
E  dE<id_i.  ijrikoil  _Les.  _vv  i  i  ii__.execuL  ioil_d eve  1 

lanoii.  .script  command  file.  Selectively  \tsed 
in  r-Dinbi  n.'it  ion  with  TELEMETRY  data  1  i  U-  pJ,iyh,irk. 

cad  :.:cr  ii;t  cetranands  t  rotn  keyboard 
ic.vl  :ci  ipi  coinmaiKl::  f  t  om  mi  i  on  . -n't  i  pi  !i!e 


1S4 


TRACE 
TRACE -ON 

TRACEOFF 
TRACE -OFF 
NOTRACE 
NO-TRACE 


L'OOPFOREVER 
LOOP ' FOREVER 

LOOPONCI-: 

LOOP -ONCE 

LOOPFILEBACKUP 
LOOP  FILE-BACKUP 


enable  verbose  print 
disable  verbose  print 


statements 

statements 


in  execncinn  level 

i n  execu  Clou  level 


repeat  current  mission  when  done. 

each  repetition  is  called  a  'replication.' 

do  not  LOOPFOREVER.  stop  when  end  of  script  in  reached 


bacb  up  output  fileL?  during  each  loop  replic.ation 
to  permit  inspectior.  while  new  files  are  written 
the  backup  files  are  in  execution  directory; 
output  .  t  elemet r/  .previous  -output  .  l_.serc.id.  previous 


ENTERCONTROLCONSTAN rs  start  a  keyboard  dialog  to  enter 

ENTER  CONTROL  CONSTANTS  revised  control  Iqofi  thin  cooflicionts 


lONTROLCONSTANTSINPOTF  1 LE  read  revised  ccnitrol  algorithm  coef  E  i  c  i  eii  i  s 
CONTROL  CONSTANTS- INPUT-FXLEf torn  file  "contiol .constants. input" 


BENCH-'^EST  Simplified  initial  command-line  eaiameter  for  q>iick 

BENCHTEST  switch  setting  during  Russ's  control  and  prop  testing 

BENCH 


NOTEXT  Eliminate  text  display  in  command  window 

NO-TEXT  (useful  for  veibose/long  runs  in  virtual  world) 


TEXT  'Turn  text  display  in  command  window  back  on 

TEXT -ON 


OUIT  do  not  execute  any  more  commands  iti  Litis  script,  but 

STOP  rep'rat  the  mission  again  if  LOOP-FOREVER  in  set 

DONE 

EXIT 

REPEAT 

R'iSTART 

COMPLETE 

<eof>  market 


K.tLL  same  as  QUIT  but  also  shuts  down  socket  to  virtual  woild 

SHUTDOWN  'dyiiamicK'  pioce-s.s. 


/  Sonat  command'-. 


/  / 


SONARRV'i  #t'i  tti  tt];  Set  the  be. 11  trig  (ttb).  i  nitje  (111),  u.c)  ixiwci  (Dij)  ui  i  lu' 

o'NArK  7v:5  #b  #r  Sp  sT-'/^S  sonar,  in  virtn.jl  world,  l.-eariiUi  in  noce'VMiy  lot 

SONAR_.'.’h  #1:  #T-  Op  ■inn.-’r  model  .  In  ,  llii-.:  :;l  ■■ii'i:  d.il.i  in  llu-  h.ile 

,';T72‘j  #b  fti  ftp  Vector  for  replay  and  cxamina;  ion . 


noNAF.  10)11  41; 

SONAR  i  UUU  ttb 
SONAR  lOOn  ttb 
L'TinilC  #b 

fICAN-WIDTH  # 
.SfANWIPTn  tt 

SONAK'ITACE 

.soNARTRACFol-'l-' 


M.inually  contiol  the  STinijU  pon.ii  beaiing  ti.  4ii  ileg i m 
leJative  to  Plioenix  lieadiiK) 

Tola)  degrees  tor  default  ETIOOLI  nonnr  scan,  centeied 
about  bow 

Enable  verbose  iJiiiit  ntat  ements  in  execution  soilat  i  ode 
r-';;;.ible  verliosi'  |iriiir  .st.iL(*meula;  in  execution  soiiri  r  code 


w 
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4 


4 


4 


4 


4 


4 


4 


4 


SONAR  INSTALLED  Sonar  interface  installed,  use  them 

SONAR -INSTALLED 


NOSONARINGTALLED  Gonar  interfile  not  installed,  don't  use 

NO-  SONAR-  INSTALLED 


//  Miscellaneous  commands 


AUDIBLE 

AUDIO 

AUDIO-ON 

SOUND  ON 

SOUNDON 

SOUND 

SILENT 

SILENCE 

NOSOUND 

SOUNDOFF 

SOUND -OFF 

AUDIOOFF 

AUDIO -OFF 

quiet 

SOUNDSERIAL 

SOUND-SERIAL 

SOUNDPARaLLEL 
SOUND-:  ARALLEL 

EMAIL 
EMAIL-ON 
E-MAIL 
E-MAIL  ON 
EMAILON 

EMAILOFF 
EMAIL-  OFF 
E-MAILORF 
E-MAIL  OFF 
NO -E-MAIL 
NO -EMAIL 
NO  E  MAIL 
NOEMAIL 


enable  texc-cc-speech  audio  output 


disable  toxt-to  speech  audio  output 


te.ll  virtual  world  to  pause  while  playing  back  sound 
(dof au 1 t ) 

tell  virtual  world  to  play  sounds  as  parallel  processes 
irhii;  may  ccuse  garbles  if  speeches  play  s imu Itnneously ) 

ask  user  tot  electronic  mail  address  at  mission  start, 
send  user  ai.  electronic  mail  report  at  mission  finish 


disable  electionic  mail  address  query  teatuie 


SLIDINUMODECOURGE  Gliiling  mode  couise  control  algoi  itlnn  (nol  yet  working) 
SLIDING-MODE-COURSE 

SLiniNGMODEOF'F  Disable  sliding  mode  course  control  algorithm  (*''') 

GL1D1NG-MODE-OF1-' 


I'ARALl-EljPOR'rrRACE  enable  trace  statements  tol  parallel  port  communications 


WAYFOlNTFOI.l.OW 
WAYPOINT -FOLLOW 
WAYI’OINTFOLLOWON 
WAYPOINT  FOLLOW  -ON 


Get  mode  to  arrive  ,it  nac:li  waypoint  hetorc  reading  the 
next  mission  s-ripl  'jonuiiaiid,  i.e.  coiiL  uiue  towards  eaoli 
waypnjnt  for  however  l-ing  it  takes  to  i:e,ieli  the  standotf 
distance  betore  pausing  to  read  Lite  nett  command. 
Probably  not  needed  .anymore. 


WAYPIJINTFOLUIWOI-T  Disable::  WAYPOINTFOl.t.OW  mode 
-JAYPOINT  l-'OI.I.OW-OFl-' 


// 


(*F 
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APPENDIX  C.  MISSION  GENERATION  EXPERT  SYSTEM  USER 

(;UIDE 


A.  INTRODUCTION 

This  appendix  consists  (d'  operating  instructions  tor  the  mission  planning  expert 
system.  Included  sections  include  startup  and  initial  operations,  tactical  level  initialization 
tile  generation,  the  means-ends  mission  planning  tacility  operation,  phase- by-phase 
mission  specification  facility  operation,  and  finally,  executable  code  generation, 
compilation  and  execution. 

B.  STARTUP  AND  INITIAL  OPERATIONS 

The  mission  planning  expert  system  requires  Quintus  Prolog  version  .^.2  and 
I'rowindows  [  Weilemaker  94].  At  present,  these  are  only  installed  on 
o  14  .  c.'s  .  npu  .  navy .  mil  located  in  the  artificial  intelligence  (AI)  lab,  however  the 
expert  system  can  still  he  run  from  anywhere  on  campus  by  .starting  a  remote  xterm.  Log 
onto  any  Unix  workstation  on  cainiius,  start  X-Windows  (if  ncces.stiry)  and  type  the 
following  from  any  xtorm  shell: 

xhost  al4.cs.nps.navy.mil 

>  tolnet  ai4 . cs .nps .navy .mil 

Log  onto  the  auv  account  on  aid  .  co  .  nps  .  navy .  mi  I  and  change  to  the 
;;t.f  at: oq  i  c  directory.  ,S  Prowiiulows  by  typing 

aid--  cd  stratBi^^ic 

aid>  xterm  -display  localmachine; 0 

Lor  this  eumiiiaiiu,  luc.ciiiiirieih aiit;  is  tiic  macl'iinc  upon  whicli  ya;u  are  working.  Alter 
'  xccLiting  this  command,  a  new  xtiorm  will  pop  up.  in  this  window  type: 

ai4>  newprowin 


•  • 
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Once  Prowindows  has  started,  the  expert  system  is  loaded  and  started  by  typing  (including 
the  period'): 

?-  [niission_.expert]  . 

This  will  cause  the  software  to  load  and  start  automatically.  To  later  restart  the  expert 
system  from  prowindows  (if  it  has  been  exited  using  the  quit  button),  simply  type 


?  -  go . 


Once  the  windowed  mission  generation  expert  system  has  started,  use  the  menu 
button  labeled  Available  Charts  to  choose  the  operating  area  ibr  the  mission  you  wish  to 
generate.  Clicking  the  left  mouse  button  over  the  menu  will  cause  the  available  operating 
area  information  (and  the  area  maps)  to  cycle  one  at  a  time.  Depressing  the  right  mouse 
button  over  the  menu  button  will  invoke  a  drop-down  menu  dis|)laying  all  possible 
operating  areas.  Dragging  the  mouse  to  the  desired  operating  area  and  releasing  the  mou.se 
button  will  cause  it  to  load.  The  cuiTcntly  displayed  map  v'dl  always  correspond  to  the 
currently  loaded  operaling  area.  The  operating  area  can  be  changed  at  ;uiy  time,  however, 
changing  the  current  operating  area  while  editing  a  mission  will  automatically  clear  all 
current  mission  data. 

It  is  also  a  good  idea  at  this  point  to  enter  the  name  of  the  desired  output  file  oti  the 
Output  Kile  Name  item  (although  the  file  name  can  he  entered  or  changed  any  time  prior 
to  code  generati('.i).  'Fhe  file  name  must  conform  to  staiuiard  I  Jnix  naming  conventions.  It 
is  best  to  add  the  .pi,  .C,  .cc.or  .  rpp  extension  appropriate  for  the  final  output 
language,  hut  this  is  not  a  requirement  o(  the  cxjicil  system  it.self.  The  naming  convention 
used  to  dale  follows  the  i'onn  minsi  on  .  jrl  .myex'nmpJ  e  for  Prolog  code  and 


III  L  Xi  a  i on  y  J.  dpi  i  .  C  .  uiy  Ini'  C  i  +  Code.  Prior  lO  COsiliiiling  or  eXcCUiip ig  the 


missions,  the  file  slurukl  he  cojiied  into  min;;ion_.graph. C  or  mission. pi  as 


appropriate.  CiiiTently  the  autogeiu  ated  Cn  code  compiles  and  runs  under  the  Silicon 


Graphics  (SGI)  Irix  operating  system  on  any  campus  SGI  workstation.  The  autogenerated 
Prolog  runs  on  the  Voyager  laptop  only  (tony .  cs  .  nps  .  navy  .mil). 

sttui  the  different  system  facilities,  the  Available  Operations  menu  buttons 
(from  the  main  menu  shown  in  h'igure  62)  are  used.  Starting  any  system  by  selecting  the 
Phase  by  Phase  Generation  or  Means  Ends  Generation  button  will  automatically  end 
any  system  facility  currently  being  executed  and  will  clear  all  data  from  that  opeiation.  Use 
ol  the  Create  Initialization  File  or  Modify  Current  Mission  will  start  the  appropriate 
facility,  but  will  not  dear  data  from  memoiy  if  another  system  facility  was  intermpted. 
Directions  for  use  of  each  of  the  system  facilities  are  provided  in  the  following  sections. 

C.  TACTICAL  i  JsVEL  INITIALIZATION  FILE  GENERATION 

When  running  all  three  RBM  layers,  tlie  tactical  level  requires  an  initialization  file. 
This  file  contains  information  such  as  the  initial  vehicle  po.sture.  the  locations  of  the 
Divetracker  units,  and  the  gyro  enor.  To  start  "cncrate  this  file,  use  the  left  mouse  button 
•o  click  the  Create  Initialization  File  button  under  Available  Operations.  At  this  point, 
the  data  is  entered  using  the  data  input  window  shown  in  Figure  63.  Data  must  he  enlereil 
using  tlie  sliding  bars  (point  and  click  usitig  the  map  is  not  enabled).  Locations  are  in  X,  Y 
coordinates  eorrcsiroiiding  to  the  grid  overlaying  the  operating  area  map.  When  fini.shed, 
use  the  left  mouse  button  to  press  tlie  Done  button  on  the  initialization  Parameters  tiata 
entry  window,  The  mlornialion  will  he  saved  in  a  file  called 

i  n  i  t  La  1  LZ.at.lon  .  script.  To  end  the  facility  without  creating  the  initialization  I'ile, 
use  tile  left  mouse  button  to  press  the  Cancel  button.  NOTH:  II  niore  than  one  mission  is 
to  he  generated,  copy  each  LrU.v.  i.a  1  i  zaLion .  script,  file  to  aiiodicr  lile  before 
creating  the  next  one  to  avttid  overwriting. 


(.♦' 


A- 


IS-) 


I'igurc  63:  Initialization  Parameters  Data  Input  Window. 
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D.  PHASE-BY-PHASE  MISSION  SPECIFICATION 


1.  Entering  New  Phases 

To  stait  the  phase-by-phase  mission  specification  facility,  use  the  left  mouse  button 
to  click  the  Phase  hy  Phase  Generation  button  under  Available  Operations.  At  this 
point.  Phase  Type  and  Phase  Summary  windows  will  be  created.  The  Phase  Type 
window  is  used  to  specify  the  type  of  phase  that  is  tc  be  entered,  while  the  Phase  Summary 
window  will  display  a  state  table  rcpre.scntation  of  the  mission  as  it  is  entered  in.  The  Phase 
Type  and  Phase  Summary  windows  arc  depicted  in  Figures  64  and  65  respectively.  To 
enter  a  phase,  use  the  left  mouse  button  to  choo.^e  the  appropriate  type  of  phase  on  the 
Phase  Type  menu.  Data  entry  for  pha.se  parameters  for  each  type  of  phase  is  via  windows 
that  vary  depending  on  the  type  ofpha.se  (all  are  similar  to  the  data  entry  window  depicted 
in  Figure  66).  The  following  section  provides  a  brief  summary  of  what  each  type  of  phase 
will  accomplish  and  what  parameters  must  be  .specified. 
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Figure  64:  Fha.se  Type  Input  Window. 
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Depth  Change:  Change  to  new  depth  whi'e  hovering  or  after  traiivsiting. 

New  depth  is  necified. 

Course  Change:  Change  to  new  course  while  hovering  or  after  transiting.  * 

New  course  is  specified. 

Transit:  Use  maximum  RPM  to  transit  to  a  new  location.  Vehicle  will  not 
stop  upon  reaching  this  new  location,  but  will  drive  through.  Transit 

location  is  specified  a.s  an  (X,  Y)  position  and  depth  is  specified  as  i 

well. 

Hover:  Transit  to  a  new  location  and  establish  a  hover.  Hover  location  is 
specified  as  an  (X.  Y)  position.  Hover  depth  and  hover  heading  are 

also  specified.  l 

GPS  I'ix:  Obtain  a  global  posi^  oning  system  fix.  No  special  parameters 
ai'c  required. 

Rotate  Sonu  •  Search:  Conduct  a  .sonar  search  from  a  specified  location  by  4 

rotati  ig  the  sonar  360  degrees.  Search  location  is  specified  as  an  (X, 

Y)  position.  Search  depth  is  specified  as  well. 

Rotate  AUV  Search:  Conduct  a  .sonar  search  from  a  specified  location  by 

rotating  the  AUV  360  dcg’-ccs  while  maintaining  a  fixed  forward  ^ 

soimi  bearing  relative  to  the  AUV.  Search  location  is  specified  as  an 
(X,  Y)  position.  Search  depth  is  specified  as  well. 

Wait:  Continue  with  current  operation  (eg.,  hover)  for  a  .specified  period  of 

time.  Time  to  wait  is  .specified.  ^ 

Recover  in  Tube:  Perform  a  recovery  in  a  recovery  tube.  Location  of 
recovery  tube  is  specified  as  an  (X,  Y)  position.  Recovery  tube 
depth  and  heading  arc  also  specified. 

In  addition  to  the  above  data  required  by  each  individual  type  of  phase,  all  types  of  ^ 

phases  require  the  following  iiifonnation: 

I’ha.se  Name:  This  can  he  made  up  of  numbers  ;nid  lettetrs  and  is  typed  in 

by  the  user.  Noblank.s  uc  allowed,  and  the  first  character  cannot  be  , 

a  capital  letter  (if  Prolog  code  is  to  he  gcncnited). 

Time  Out:  Tliis  is  the  amount  of  time  (m  .seconds)  that  the  phase  has  to 
succeed. 

lot 


t 


Phase  Complete  Successor:  The  name  of  the  phase  to  execute  upor 
successful  completion  of  the  phase  currently  being  entered. 

Phase  .\bGrt  Successor:  The  name  of  the  phase  to  execute  upon  failure  of 
the  phase  currently  being  entered. 


The  means  of  data  entt  y  varies  depending  on  the  type  of  data.  Numerical  data  can 
be  entered  using  the  sliders.  The  slider  ranges  for  X  positions,  Y  position:;,  and  depths  are 
defined  according  to  the  current  operating  area.  Positions  for  hovers,  transits  and  searches 
can  also  be  entered  by  clicking  the  desired  position  on  the  area  map  with  the  left  mouse 
button.  The  name  of  the  pliase  is  typed  in  by  the  user  at  the  Pha.se  Name  text  entry  location. 

Push  button  menus  are  u.sed  to  enter  the  Phase  Complete  Successor  and  Phase 
Abort  Successor.  The  names  of  all  phases  that  have  been  specified  previously  will  have 
pushbuttons  on  iioth  menu.s  (in  addition  to  .selections  for  Mission  Abort  and  Mission 
Complete).  To  set  one  of  these  phases  as  itic  complete  or  abort  successor,  simply  use  tlic 
left  mousf',  buPen  to  .select  the  desired  phase.  If  the  desired  .successor  (ihasc  has  not  yet  been 
defined,  use  the  left  mou.se  button  to  select  the  Urspecified  menu  item.  A  new  data  entry 
window  for  specifying  the  name  of  the  succcs.sor  pha.se  will  then  be  displayed.  Enter  the 
intetidcd  name  of  the  successor  phase  on  the  Name  blank  and  use  the  Icfl  mouse  button  to 
pres.s  the  Ok  button.  Thi.s  phase  will  need  to  be  specified  later  (using  the  conect  name)  or 
an  error  will  be  generated  when  the  system  parses  the  mission  prior  to  code  generation. 

Any  phase  informatiori  can  be  clianged  after  being  entered  simply  by  re-entering  it. 
Wlicn  all  required  phase  information  ha,s  been  entered,  use  the  left  mouse  burton  to  pres.s 
the  Done  button  on  the  data  entry  window.  The  pha.se  will  then  be  stored  in  memory  and 
displayed  in  the  slate,  table  ol'  the  Phase  Summary  window.  To  cancel  emry  of  the  eun'ent 
phase,  use  the  left  mou.se  burton  to  pres.s  th  *  Keset  Phase  button  on  the  data,  entry  window. 
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NOTE:  Mi:ision  specification  can  be  interrupted  at  any  time  io  create  the  tactical 
level  initiatialization  file  without  losing  phases  th:u  have  been  specified  previously 
(restarting  the  phase-by-phase  specification  facility  is  discussed  later).  If  the  mcan.s-ends 
mission  generation  facility  is  invoked  or  the  phase-by-phase  ntission  specification  facility 
is  restarted  improperly,  however,  all  previously  specified  phases  will  be  deleted  from 
mcmon'. 

2.  Modifying  and  Deleting  Phases  Si>ecified  Phases 

To  modify  a  pha,se  that  has  been  previously  entered  without  deleting  it,  use  the  leit 
mouse  button  to  select  the  Modify  Phase  button  in  the  Phase  Type  window.  A  Phase 
Modification  window  .similar  to  the  one  shown  in  Figure  67  will  be  displayed.  Use  the  left 
mouse  button  to  select  ihc  name  of  th<'  phase  that  you  wish  to  modify  from  the  menu  in  this 
\N  indow  (or  the  Re.set  button  h)  remove  the  window  without  modifying  a  phase).  A  data 
entry  window  for  this  phase  (with  the  phase  data  as  previously  entered)  will  be  di.splaycd. 
Data  can  be  entered  using  this  window  as  if  tlie  pha.se  were  being  initially  specified.  To 
remove  tiie  window  witliout  clianging  the  phase,  use  the  left  mou.se  button  to  press  the 
Re.set  Phase  button,  or  press  the  Done  button  to  store  the  cliangcd  phase  definition. 

To  delete  a  phase  that  has  been  previously  entered,  use  the  left  mouse  button  to 
select  the  Delete  Phase  button  in  the  Pha.se  Type  window.  A  Pha.se  Deletion  window 
similar  to  the  one  shown  in  Fignie  67  will  be  di.splaycd.  Use  llie  left  mouse  button  to  .select 
the  button  coiTcsponding  Io  the  phase  to  be  deleted  (or  tlie  Re.set  hution  to  remove  the 
window  without  deleting  a  pha.se). 

II  no  phases  have  been  previously  entered  into  liie  system  and  Ihv:  ModifY  Pha.se  oi 
Delete  Pha.se  button  is  depressed,  an  error  window  will  Im  'iisplayed  Use  itu  r  ii  "ii 
button  to  press  the  t,ik  button  in  the  error  window  to  clear  the  erior  rue;,.'  !"■  V  lii-n  flom- 
spe.eityin;',  ihc.  inis.sioti,  do  not  press  the  (,'aiicel  biUlon.  Uaiher  lollow  ilie  m.  ■  ■■  ■■  '  hu 

v.enerutiou  ol  c'xei:ul.il)lc  code  provided  in  Section  F. 
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1  ii’urt.'  ill',  (a)  i’lia'-i'  \l(Hliti(  :ilu)ii  aiul(l>)  Phase  Deleluin  Wiinliiw s. 

3.  I’liast'  I’.rrors 

II  llie  ilala  enieretl  Ini  a  phase  is  I'Ualiil  in  iiu  oiii|ilele  when  ihe  Done  hutloii  is 
pressed,  an  error  inessape  will  he  displased  ilesenhiiip  llie  type  orerroi  in  an  invalid  I’ha.se 
window  similar  lo  die  one  shown  in  i-ie.iiie  (>h  I’ha.ses  eoniaiiniip  errors  will  noi  I..’ 
aeeepled  hv  die  s\sU'iii.  I'o  eleai  die  eiror  message  use  die  led  mouse  Initloii  lo  piess  die 
Ok  lull  Ion  III  die  1  1  loi  is  iiulow  I'liase  daia  ean  llieii  Is  ■•nieied  or  ehaiiia’il  as  apimipi  iaie, 
oi  ill'.'  Uestd  l'lli^^e  hiiiioii  ean  In  ir.ed  lo  eaiieel  phase  eiiiry 


1  I'Mir,-  fiX.  Iii'.aiul  I’hase  l.iioi  Kepoi  I  Window. 


4.  Mission  .Modiliealioii 

'  die  S’tiase  id  pe  ss  iir.lov.  e.  n-  il  inesenl  and  i iii''Sioli  ejm  il  r  al  inii  is  iioi  eoiiipli'Ie 
■  III  ssii '  1 1  u  al  ioi ,  .  ..•  I  hr  I  11.  I II  lei  I  v,  illioiii  ele.ii  am  j n  'W- n xisK  so'  i  1 1  led  phases  1 1  on  i 


memory  by  using  the  left  mouse  button  to  select  the  Modify  Current  Mission  button  on 
the  Available  Operations  menu  of  the  main  system  menu.  Loss  of  the  Phase  Type 
window  can  have  a  number  of  causes.  The  most  common  is  accidental  (or  intentional)  u.se 
of  the  Cancel  button  on  the  Phase  Type  window.  The  Phase  Type  window  will  also  be 
removed  if  the  Create  Initialization  File  facility  is  invoked.  It  may  also  be  the  case  that 
the  window  is  simply  hidden  by  another  window  on  the  screen.  Regardless,  use  of  the 
Modify  Current  Mission  button  will  generate  a  new  Phase  Type  window.  Mission 
specification  Caii  then  proceed.  If  the  Modify  Current  Mission  button  is  pressed  when  no 
specified  phases  are  contained  in  memory  (either  no  pha.ses  have  been  specified  or  memory 
was  cleared  by  the  invocation  of  one  of  the  other  sy.steni  facilities),  an  error  message  will 
I  ic  displayed.  To  clear  the  error  message,  u,sc  the  left  mouse  button  to  press  the  Ok  button 
on  the  enor  window, 

5.  Code  Ccneriition 

Once  mission  s[)ecifieation  is  complete,  code  can  be  generated  by  following  the 
instructions  in  vSection  F,  i'.xecutable  ( 'ode  Generation,  Compilation  and  Operation. 

F.  MISSION  CFNKRATION  WH  H  MRANS-ENDS  ANALYSIS 

1.  Overview  and  Laundi  and  Kecovt  -  ■  Position  Specification 

The  nicaiis  ends  lai  ility  is  usinl  t"  aiilomaiicallv  generate  complete  missions  by 
specifying  the  AllV  launch  position,  recovery  nii.sMon,  type  "f  recovery  ami  the  goals  of 
the  mission.  To  invoke  this  facility,  u.se  the  left  mouse  hiitluii  to  pres.,  the  Means  Ends 
Generator  bnlton  on  the  Available  Operations  menu  of  the  main  window.  The  system 
will  disiila)  ilie  window  sliown  in  Figure  bh.  Use  llie  slitler.  i  i  tliis  window  to  enter  the 
A1 JV  launch  ami  rei overy  iiosiiioiis  (^[iiiinl  and  eliek  is  not  enahicd ).  'I'lii  i  window  is  also 
used  to  dei  inc  tlic  tyjie  of  reeoveiy  to  be  exeeiited  at  the  end  of  the  mission  and  enter 
loi  alions  to  be  searched  during  the  mission. 
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routing  to  the  search  point,  ise  the  tran.sit  point  location  field.  The  generated  mission  will 
cause  the  AUV  to  transit  through  this  point  prior  to  establishing  a  hover  at  the  search 
location  (if  the  search  poitn  atid  transit  point  arc  collocated,  the  AUV  wilt  transit  directly 
to  the  search  point  and  establish  a  hover).  This  point  can  he  specified  using  the  slitle.  s  or 
by  indicating  the  transit  point  localioii  on  the  area  map  using  the  right  mouse  button  (after 
the  search  location  has  been  specified  manually  or  with  the  left  mouse  butten).  To  save  the 
search  data,  use  the  left  mouse  button  to  press  the  Store  Point  button  in  the  Search  Point 
Data  window.  To  cancel  .search  point  entry  without  saving  the  .search  point  data,  use  the 
Cancel  button  in  the  Search  Point  Data  window.  Once  a  .scarchpoint  has  been  entered  into 
the  system  and  saved,  it  cannot  be  saved.  All  .search  points  can  however  be  deleted  from 
memory  by  using  the  left  mouse  button  to  pi  ess  the  Clear  Search  Points  button  in  the 
Means  End  Help  window. 


Figure  71:  Search  Point  Data  Hiilry  Window. 

4.  Computing  a  Sequeiicc-  of  Pliases 

Once  the  launch  position,  recovery  position,  type  of  recovery,  and  scarchpoi’Us 
liave  been  siiceiticd,  the  system  can  be  used  to  generate  a  sequence  of  phases  that  will 
aecouiplish  tlie  mission.  To  invoke  this  feature,  use  the  left  mou.se  button  to  press  the 
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(Jenerate  Phase  Sequence  button  in  the  Means  Knd  Help  window.  The  sy.stcni  will  then 
j’enerate  the  sequence  of  phases  and  display  a  textual  liescription  of  the  le.siilting  mission 
in  a  window  similar  to  the  one  shown  in  Fugurc  72.  In  addition  the  path  of  the  mission  will 
be  depicted  on  the  area  map  of  the  main  system  window. 
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1-igure  72:  .Sample  Means  binds  Analysis  Mission  Solution  Window. 


.Sinee  means-ends  analysis  is  not  guaranteed  to  liiid  the  best  solution  lirsl.  the 
cai'jability  e.xisls  to  cycle  through  all  jrossible  solutious  one  al  a  tiitie.  To  giaierate  another 
solutuin  usirii'  means-ends  analysis,  use  the  left  mou.sc  button  to  press  the  Next  Solution 
bution  in  the  Mean.-:  End  .Solution  window.  A  new  solution  will  he  computed  and 
displayed  textually  in  a  Means  Find  Solution  wiinlow  and  geographically  on  the  area  ma]i 
of  the  main  wintlow. 


\i: 


5.  Code  Generation 

Once  mission  specification  is  complete  and  a  satisl'actoi7  solution  has  been 
obtained,  code  can  be  generated  by  following  the  instructions  in  Section  b,  hxecutable 
Code  Generation.  Compilation  and  Operation. 

F.  EXKClJTABLE  CODE  GENERATKiN,  COMPILATION  AND  OPERATION 

1.  Code  Generation 

Kxecutable  code  can  be  generated  based  on  a  mission  .specified  using  the  phasc-by- 
phase  mission  specification  facility  or  the  nieans-ends  mission  generation  facility.  If  the 
pha.se-by-pha.se  mission  specification  facility  was  u.sed  to  specify  the  mi.ssion.  the 
genenued  executable  code  will  correspond  to  the  mission  de.scribed  in  the  Phase  Summary 
window.  If  the  meams-ends  analysis  mission  generation  facility  was  used,  the  generated 
executable  code  will  correspond  to  the  mission  described  in  the  current  Means  End 
Solution  window. 

To  generate  executable  code  simply  u.sc  the  left  mou.se  button  to  piess  the  Generate 
Mission  ('ode  button  in  the  main  system  window.  If  the  jihase  by-phase  mission 
specification  facility  was  used  to  .specify  the  mission,  the  system  will  rciiuest  the  natiie  of 
the  first  ]ihasc  of  the  inission.  Simply  use  the  left  mou.sc  button  to  select  the  approptiate 
first  phase  from  the  menu  displayeil.  11  the  means  ends  mission  generation  faciliiy  was 
used,  this  step  is  not  leiiiiiied.  In  either  case,  the  syNlcni  will  parse  the  mission  to  check  I’oi 
errors  (loops  in  the  graiih,  no  mission  complete  .s|iecificd,  uns[)e.cified  iiha.ses,  etc.)  jiriur  to 
generating  code. 

It  errors  are  detected,  a  window  similar  to  the  one  in  Pigure  Td  will  be  displayed. 
To  clear  the  error  message,  use  the  left  mouse  button  trr  juess  tlie  Ok  button  in  the  Pha.se 
Error  window'.  I'he  mission  c;in  be  then  edited  using  the  phase -by  |)b.;i.se  mi.ssion 
specification  facility  or  inctins  ends  mission  g.eneration  lacility  ;is  appropriate  (the  only 


errors  that  can  be  introduced  by  the  means-ends  mission-generation  facility  are  caused  by 
manually  changing  the  recovery  position  when  a  tube  recovery  is  requested  as  described 
above).  Editing  of  missions  wit!  errors  is  conducted  as  if  no  attempt  to  generate  code  had 
been  made. 


Figure  73;  Error  Window  for  Detected  Mission  Errors. 


If  no  errors  are  detected  during  parsing,  the  window  displayed  in  Figure  74  will  be 
displayed.  To  select  the  desired  language  for  output,  use  the  left  mouse  button  to  press  the 
Prolog  or  C-(-4-  button  as  appropriate.  The  output  file  will  be  tored  in  the  current  directory 
(~auv/ strategic)  and  will  be  named  according  to  the  Output  File  Name  entry.  If 
Prolog  code  is  generated,  an  additional  file  will  be  created  with  a  standalone_,  added  to 
the  beginning  of  the  nam.;.  These  two  files  are  equivalent  except  that  running  the 
standalone  file  will  make  queries  to  the  user  rather  than  the  tactical  level.  To  clear  this 
window  without  generating  code,  press  the  Cancel  button. 


Figure  74:  Output  Language  Selection  Window. 


2.  Compiling  and  Running  the  Mission 

a.  The  Tactical  Level  Initialization  File 
To  run  a  mission,  generated  files  must  be  transferred  from 
ai4  .  cs  .nps  .  navy.mil  to  the  appropriate  directories  on  file  system  of  the  machine 
upon  which  the  tactical  level  is  to  run.  All  files  should  be  transferred  as  ascii  files  using 
the  Unix  ftp  facility. 

The  initialization,  script  file  should  be  transferred  to  the 
~auv/  tactical  directory  (or  ~auv/uvw/ tactical  on  the  Sun  Voyager)  regardless 
of  the  language  generated  by  the  expert  system.  When  running,  the  tactical  level  requires 
the  file  to  be  called  initialization .  script,  but  for  storing  multiple  initialization 
files,  it  is  ok  to  use  different  names  (eg.,  .extensions  for  describing  what  mission  the 
initialization  file  is  for).  An  example  ftp  .session  is  shown  below.  This  session  is  conducted 
from  the  strategic  directory  on  ai4  .  cs  .  nps  .navy.mil  (from  the  xterm  window). 
ai4>  £tp  g'ravya.cs.npB.  navy  .ail 
username:  auv 

password: 
ftp>  cd  strategic 
£tp>  put  mission_graph..C.exaii:ple 
ftp>  cd  ../tactical 
ftp>  put  mission. pi. oxaiopta 

£tp>  put  initialization. script  .initialization. script . exanq;>le 
£tp>  put  coinnLand_Btrings  command_strings .lAxample 
ftp?  <iuit 

In  this  example,  it  is  assumed  that  a  Prolog  and  a  C+i-  mission  were  generated.  If  only  the 
C++  version  was  created,  the  put  mission.pl .  example  command  can  be  omitted. 
If  only  a  Piolog  vers'on  was  created,  the  cd  strategic  and  put 
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mission_graph .  C .  example  can  be  omitted  and  the  cd  .  .  /  tactical  command 
should  be  modified  to 

ftp>  cd  tactical 

b.  Prolog  Execution 

If  Prolog  code  was  generated,  the  standalone  file  (standalone_  prefix) 
should  be  placed  in  the  ~auv/  strategic  directory  on  the  target  machine.  The  mission 
file  itself  should  be  placed  in  the  -auv/ tactical  directory.  Either  of  these  files  can 
have  any  name  so  long  as  they  end  in  the  Prolog  .  pi  extension  (and  contain  no  other 
periods).  To  run  the  standalone  strategic  level,  switch  to  the  ~auv/  strategic  directory 
on  the  appropriate  machine  and  start  Prolog  (or  Prowindows).  Load  the  mission  into 
memory  by  typing  the  file  name  (minus  the  .  pi  extension)  in  brackets  followed  by  a 
period: 

?-  [mission] . 

To  run  the  mission,  type: 

?-  execute_mission. 

Answer  the  strategic  level  queries  by  typing  yes  or  no.  To  nm  the  mission  in  the  vehicle  or 
the  virtual  world  (tactical  level  attached),  switch  to  the  ~auv/ tactical  directory.  It  is 
probably  a  good  idea  to  mal»e  sure  the  proper  version  of  the  tactical  level  has  been 
compiled.  To  do  this  type: 

>  make  strategic 

Start  Prolog  and  load  the  mission  file  into  memory  by  typing  the  file  name  (minus  the  .  pi 
extension)  in  brackets  followed  by  a  period,  just  as  for  the  standalone  version  of  the 
strategic  level.  The  mission  is  started  in  the  same  way  as  the  standalone  version  as  well: 

?-  execute_mission. 
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c.  C++  Compilation  and  Execution 

If  the  expert  system  generated  a  C++  strategic  level  mission,  it  must  be 
compiled  prior  to  running  the  mission.  The  generated  C++  file  should  be  transferred  to  the 
~auv/  strategic  directory  on  the  appropriate  file  system.  Before  compiling,  the  C-i+ 
mission  file  must  be  named  miss  ion_graph .  c  and  must  be  located  in  the  strategic 
directory.  To  compile  the  mission,  from  the  auv  directory  and  type: 

>  cd  strategic 

>  cp  iaission_graph.C.exeunple  iaission_graph.C 

>  cd  ../tactical 

>  make  r-trategic_cpp 

The  executable  file  upon  completion  of  the  make  will  be  located  in  the  tactical 
directory  and  will  be  called  strategic.  To  make  a  standalone  version  of  the  mission, 
type: 

>  make  strategic_st2uidalone 

from  the  tactical  directory.  The  executable  standalone  mission  will  be  placed  in  the 
tactical  directory  and  will  be  called  ood_test.  Either  the  standalone  version  of  the 
strategic  level  or  the  full  RBM  version  are  invoked  by  typing  the  name  of  the  executable 
file  on  the  command  line. 

G.  EXITING  THE  SYSTEM  AND  INDIVIDUAL  FACILITIES 

To  exit  the  system  at  any  time  during  execution,  use  the  left  mouse  button  to  press 
the  Quit  button  in  the  main  window.  The  Prowindows  interpreter  can  be  "'  ted  by  typing 

?-  hal+. 

Most  system  windows  provide  a  Cancel  button.  Pressing  this  button  using  the  left 
mou.se  button  will  cancel  the  operation  without  performing  it.  As  a  rule,  use  this  button  to 
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cancel  operations  and  destroy  windows  rather  than  the  minus  button  in  the  upper  left 
window  comer. 
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